E-project management of the new e-reality
by Peter Kulik and Robert Samuelsen
Managing your business electronically is no longer the wave of the future—it is here now! How does project management fit into this new way of doing business?
A WELL-KNOWN STUDY by McKinsey and Company found that hightech 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.
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.
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.
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:
■ E-projects are iterative by nature—multiple iterations are the rule and users expect them. Incremental new features can be introduced—and bugs fixed—in real time.
■ Speed is of the utmost importance in e-projects. Typically it makes business sense to trade off scope, cost, and/or quality to accelerate the speed of project completion.
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.
Reader Service Number 084
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.
“4D” e-Process for New Construction
Exhibit 3. This graphic depicts a high-level process model for new construction e-projects.
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.
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.
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.
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.
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.
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.
e-Process for Remodeling
Exhibit 4. The high-level process model can be simplified for remodeling e-projects to support rapid turnaround.
Reader Service Number 085
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:
■ Streamline—don't abandon—processes.
■ Make a living plan for the next two or three iterations.
■ Add structure to accommodate iterative release cycle processes.
■ Fit planning effort to around 10–20 percent of projected project effort.
■ Plan testing based on risk.
■ Use automated tools for testing and site integrity.
■ Implement time-based metrics such as cycle time.
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.
Exhibit 5. These data fields can be used to create a simple template to track and control micro-releases.
Reader Service Number 086
PM Network March 2001