PM Network Online

e-Project Management for the New Reality


by Peter Kulik and Robert Samuelsen

A well-known study by McKinsey and Company found that high-tech projects completed on time but up to 50 percent over budget were nearly 25 percent more profitable than projects completed six months late but on budget. [This study is cited in a number of public sources: for example, http://www.pivotint.com/index.html; http://www.processgroup.com/cycletime.htm; http://www.leapworks.com/frameworks/glfpd/overview.html] Today’s e-business environment has amplified this finding, moving at the incredibly fast pace of what has been called “Internet time.” This pace is driven by market conditions and the speed at which new technology has evolved. Time compression creates unique challenges for project managers and, while many have been tempted to discard project management in the new environment, project management has become even more important.

Readers of PM Network are familiar with project tradeoffs of time, cost, and quality, and the idea that it is impossible to maximize all dimensions simultaneously because of the constraints inherent in each parameter. The nature of e-business shifts e-project tradeoffs to focus on time with pressure for tradeoffs in quality and cost to achieve aggressive cycle times.

Most e-projects differ from traditional software projects in two key dimensions: the frequency of releases is higher; the scope of what is deployed in each release is smaller. While major e-services redesign or redeployment (for example, Wal-Mart’s recent deployment of a new e-store) are similar in many ways to traditional software projects, the modularity and (mostly) common GUI lends itself to incremental updates over time. These incremental updates—new features, new content, and fixes—have unique attributes that demand project managers take a different approach to remain relevant.

The differences between e-projects and traditional projects suggest a process and framework for e-project management that adapts proven project management rigor for use in the fast-paced, time-crazed new economy.

Project Characteristics
For the purposes of this article, an e-project is any project that involves creating or changing source code that is deployed on the Internet. This includes a range of projects from new content deployment in HTML to applet enhancements in Java and ActiveX. As shown in Exhibit 1, most e-projects are distinctly different from traditional projects along two key axes: release frequency and software size. Traditional projects are typically six months or longer in duration and include development of more software, whether measured in lines of code, function points, use cases, web pages, or other measures. Most e-projects are typically shorter—from days to a few months—and are much smaller than traditional projects.

Some key attributes of e-projects:

There are typically three “classes” of e-projects: new construction, remodeling, and maintenance—not unlike building a house. In almost all cases, they are measured in months, weeks, and days, respectively. The time frame of “years” is not in the vocabulary for e-projects!

Software Project Management Map

Exhibit 1. Traditional project management is highly evolved to deliver large software projects with relatively long release frequencies; the realm of e-Project Management is small software projects with short release frequencies.

New Construction. This class represents the initial build of an e-project, and falls in the area to the right of the vertical line in the software project management map in Exhibit 1. Just like a new house, cost/benefit analysis, blueprints, approvals (such as building permits), contracts, and legalities are essential steps. It may take months to complete the initial implementation of an e-project. To develop a new online store or a business-to-business exchange might take months.

Remodeling. New feature introductions are typical of remodeling e-projects, which fall in the “e-PM” zone in Exhibit 1. Just like a house, whereby you continue to live in the house during the room addition, new feature introductions are typically done while the online service continues to operate. Due to the dynamic modularity of HTML, new features can be added with little disruption and made available to users immediately. Typically, remodeling projects take weeks to complete.

Maintenance. Every homeowner knows the need for constant maintenance. E-systems are no different, with maintenance performed in real time. Maintenance can include bug fixes, minor enhancements, content changes and additions, and other mundane tasks. Deployment of maintenance projects can occur one or more times a day.

As an Internet site or service evolves, remodeling iterations may dramatically transform it over time.

A summary comparison of traditional and e-projects is shown in Exhibit 2.

Comparison of Traditional and e-Projects

Exhibit 2. The differences between traditional software projects and e-projects drive a 
different approach for e-project management.

Process Challenges
Perhaps the biggest challenge in an organization and its e-projects is the “apparent” abandonment of internal processes. Traditional product realization processes have been built over many years and often reflect the culture and hierarchy of the organization. Each step in the process is measured against existing standards prior to advancing to the next step. The traditional “waterfall” process model is focused on quality and cost concerns, with less regard for time. Breaking this paradigm is uncomfortable and unpopular in highly structured organizations.

Nevertheless, the overriding importance of time drives modifications in existing processes, evidenced by the proposal of “light” methodologies by several industry sources. Seven or eight process steps must be reduced to three or four. Five or six layers of signature signoff must be reduced to one, two, or three. While some Internet pundits may claim a complete abandonment of process, we believe there is still a need for process—perhaps more than ever before—to maintain control over the e-business technical infrastructure. However, processes must adapt to the focus on speed, allowing for employee empowerment and organizational creativity.

In fact, there may be three different processes: one for new construction, one for remodeling, and one for maintenance.

“4D” e-Process for New Construction

Exhibit 3. This graphic depicts a high-level process model for new construction e-projects.

New Construction. New construction should follow an accelerated implementation of existing software development processes or adaptations thereof. For example, a simple four-step process for new construction might be such as found in Exhibit 3.

In this “4D” e-process the discover phase is focused on the business analysis of the project. The design phase is used to create requirement documents, technical specifications, and acceptance criteria. Obviously, the develop phase is for programming, graphic design, technical implementation, and quality assurance. The deploy phase includes marketing activities and other post-release activities such as customer service, operations, and fulfillment.

e-Process for Remodeling

Exhibit 4. The high-level process model can be simplified for remodeling e-projects to support rapid turnaround.

Remodeling. The remodeling process will be an accelerated implementation of the new construction process with the focus on iterative design and develop phases. Usually discovery and deployment issues are associated with the whole project, not just new feature introductions, unless the remodeling project directly impacts those phases.

The remodeling process is iterative, as illustrated in Exhibit 4. Remodeling projects are ongoing and rapidly cycle through the design and develop phases. Unlike new construction, these projects are not necessarily planned well in advance but rather are part of an ongoing enhancement cycle.

This type of activity must be anticipated, allowing for flexible resource allocation (financial and human resource) and rapid turnaround.

Micro-Release Template

Exhibit 5. These data fields can be used to create a simple template to track and 
control micro-releases.

Maintenance. The maintenance process is empowered through a microrelease process. If there are many “maintenance releases” a day, process rigor must be streamlined to accommodate very fast execution of configuration management. This iterative and dynamic process can be accomplished with a single microrelease page, such as is shown in Exhibit 5, similar to what is in use today by one of our clients. In this microrelease scenario, each maintenance item is tracked through a series of one-page forms, kept in a notebook, and logged with other project deliverables. And just as the process is rigorous, resources need to be organized to accommodate these types of changes. 

e-Project Management
Releasing new features ahead of competitor websites can increase traffic, improve visit “stickiness,” and increase return visits. All of these can drive increased transaction and advertising revenue, providing a company can stay ahead of and differentiate itself from fast-moving competition.

Schedule management, scope management, quality management, and release management are key aspects of project management for e-projects.

Schedule management of e-projects with real-time deliverables involves a balance between planning and the complexity of work to be done.

Schedule planning and management for major releases should be comprehensive, can often be streamlined significantly for feature releases, and may be nonexistent for microreleases. If schedule planning and management is benchmarked at 10–20 percent of total project effort, for a three-month major release, schedule planning and management should be on the order of one to two weeks. Schedule planning and management should not take more than one to two days for a two-week feature release.

Closely tied to schedule management is scope management. Scope must be managed so that the schedule can be achieved. This can involve ruthlessly managing scope creep—moving new features out and managing microreleases. As discussed below under release management, regular release cycles can significantly aid in managing scope by providing a foundation for feature-function phased introduction.

In traditional software development, quality management involves ensuring adequate testing and defect density below targets to minimize the likelihood of customer-discovered bugs. E-project quality management has a similar objective with the advantage of daily (or even multiple daily) releases possible to correct faults in “released” software and real-time feedback from website users identifying faults. To accelerate time to market, an e-project can take advantage of the Internet environment to make risk-based decisions, eliminating just the most serious faults, ensuring that the integrity of the site (much of which can be done using automated tools) and completing additional testing and fault repair in real-time on the live site, leveraging users as testers. 

Release management in e-projects is a critical area for e-project management. Traditional software projects (and new construction e-projects) typically have releases once every six to 12 months or more, depending on the nature of the software being released. Traditional software releases usually involves burning CDs, documentation updates, packaging, and distribution, making it costly to release more often. In some cases, software patches can be released on a weekly or monthly basis depending on the severity of the faults they fix.

E-projects, on the other hand, can have daily releases, or even multiple daily releases. To maintain control, sites such as Microsoft, MSNBC, Compaq, Cisco, and others indicate the dates and times of the latest updates directly on the web page. These may change daily or on a minute-by-minute basis for news services. Delta-Air, for instance, shows a version number in its HTML source code, and Merant actually shows recent maintenance releases in its HTML source code.

Recent failures at well-established sites such as Amazon.com and E-Trade highlight situations in which controlling e-project release cycles becomes critical to maintaining the integrity of the site or service. Yet the browser GUI hides complexity that can make configuration management more complex by an order of magnitude or more. For example, this complexity can include applets in Java for Netscape users and Active/X for Internet Explorer users, HTML source that varies for different browsers to optimize the user interface, and audio and video formats for different multimedia players.

Distribution costs and efforts for Internet-deployed software are very low because there are no CDs to burn, no user manuals to print, no packaging to complete. Resulting from this “ease of software update” phenomenon is the temptation to release fixes quickly and frequently. However, the growing complexity of websites and services can make it difficult to “back out” fault-causing changes. Frequent software updates need to be expedited through procedures that allow them to be managed and controlled carefully, and the three classes of releases need to be mapped into planned release cycles.

Managing an e-project can be an exhilarating experience for a project manager if there is unified support and cooperation. Learning to adapt existing rigor to an e-project will cause you to reevaluate traditional ways of project implementation. Some good points to consider are:

A good e-project is not absent of project management. Rather, a different type of rigor is required. Recognizing the importance of speed, maintaining good configuration management, and managing iterative release cycles will help you be successful in your e-projects.

Peter Kulik is an independent consultant with more than 15 years industry experience. He is based in Dayton, Ohio, USA, and is co-founder of KLCI, specializing in software project management, metrics, and business development. He is also a long-standing member of PMI®.

Robert Samuelsen is an independent consultant with more than 16 years of industry experience. He is based in Ithaca, N.Y., USA, and is founder of Samuelsen eCommerce Enterprises LLC, specializing in e-business practices. He was formerly worldwide director of Internet Banking at NCR Corp.