In this paper, the term “e-commerce” has been used to connote Information Systems built to carry out Commercial transactions over the web. These systems are popularly called as Portals. If the Commercial transactions is between Business entities the portal is classified as Business To Business (B2B) Portals. These portals are commonly used in areas such as Supply Chain Management (SCM). If the Commercial transactions is between Business and End-Customer the portal is classified as Business To Customer (B2C) Portals. Examples are online stores such as amazon.com.
For the rest of the paper the term “e-commerce portal” indicate both B2B and B2C systems.
The term “e-project” has been used in context of building “e-commerce portals.” An e-project is different from traditional software projects in many ways. Firstly, the projects are normally short duration projects. The total time for building an e-commerce portal may not exceed six months. Some e-commerce project may have total elapsed time of few days. Secondly, e-projects have frequent releases. These releases may not be elaborate and may actually tweak the look and feel or add few more functionality. Finally, e-projects are the most unlikely candidates for the traditional waterfall software development methodology.
With the worldwide euphoria of organizations trying to make a foothold in cyberspace, there is a huge demand for building e-commerce portals. Project Managers trained in traditional software development methodologies are facing challenges unique to the task of building e-commerce portals. This paper discussed few challenges Project Managers encounter while managing e-projects. Some solutions, which Project Managers can use, have also been discussed.
The paper starts with a brief discussion on iterative “Project Management Framework” that can be adopted for e-projects. Next some of the challenges faced in each of the Project Management Knowledge Areas are discussed (PMBOK® Guide, 1996).
Lastly, the paper discusses points to be remembered while selecting an appropriate programming tool for building the e-commerce system.
Project Management Framework
Software Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to deliver, successfully, a product that meets the needs of both customers (the payers of bills) and the users. The fact that so few projects are unarguably successful is comment enough on the difficulty of the task (Kruchten 2000).
As mentioned earlier e-projects do not fit the Waterfall model that is the traditional software development methodology. Waterfall model assumes existence of scope-gods who have a correct and complete understanding of the business need. The analyst and designers building the portal have to gather requirements from these scope-gods. The presumption that the customer knows his requirement is flawed right at the beginning. Add to this the fact that organizations typically will have several such scope-gods and the actual scope can be arrived at after several joint review sessions with the stakeholders.
E-projects follow the 4D process of Discover, Design, Develop and Deploy (PM Network 2001). The requirements gathering phase is one of helping the client discover his requirements and capturing it in multiple iteration with more elaboration. As the requirements crystallize through joint reviews and workshops new complexity and questions arise. Thus e-projects are intrinsically iterative in nature. The use of an iterative approach leads to an in-depth understanding of business need through successive refinements and incremental growth of an effective solution over multiple cycles. An iterative approach makes it possible to accommodate tactical changes in requirements, features or schedule. In order to control scope, there may be a need to work on “fixed” time approach to complete as much iteration as possible in a set time frame. For large projects, the development of the subsystems may be done in parallel.
Process Frameworks such as the Rational Unified Process are particularly useful for e-project management and engineering. There are variations to these modern process frameworks but all of them require that an initial version of the system be rapidly constructed early in the development process. The emphasis is on addressing high risk-areas, stabilizing the basic architecture and refining the driving requirements. Development then proceeds as a series of iterations, building on core architecture until the desired levels of functionality, performance and robustness are achieved. These iterations are called by several names such as spirals, increments, generations and releases. An iterative process emphasizes the whole system rather than the individual parts. Risks are reduced early in the life cycle through continuous integration and refinements of requirements, architecture and plans. The downstream surprises that plague software projects are avoided (Royce 1999).
For details regarding phases, iterations in each phase and artifacts produced at each phase one can refer (Kruchten 2000).
Project Management Knowledge Areas
Project Integration Management
The main impact of iterative development methodology is that the Project Manager has to spend more effort for Project planning (Kruchten 2000). He has to develop a plan for each iteration in addition to an overall plan, which gives the complete picture. There is a misconception that the Project Manager should develop comprehensive detailed plan right at the beginning of the project. The reality is that a detailed plan will become obsolete by the time you finish your first iteration. Your near term plan should be in details; in accordance with your knowledge of the task you have to perform and the artifact you have to create. You may create a detail iteration plan for this. Your future iteration plan may be left at a high level.
A distinguishing feature of e-projects is the need to have a distinctive look and feel that will attract customers. This is especially true while building B2C portals. The creative artists have to work in parallel with the web programmers who are building the web application. Creative groups are right-brained guys who have to work in close collaboration with the left-brained web programmers. A proper selection of web development technology (for example JSP and not Servlets for presentation layer) will help the Project Manager in achieving high collaboration and minimum impedance between these specialized groups.
Project Scope Management
While the project manager would like to clearly define the scope of his project customers try to incorporate more and more different functionality in the same release. The only way to manage this continuous scope change is to build the portal in iterations. Functional changes or additions can be grouped together and introduced in the next release. The Project Manager should guard from customers attempt to add more and more functionality as the project proceeds through iterations. Each iteration should elaborate the functionality as per the scope decided earlier rather than introducing additional functionality. For example an automobile portal may want to introduce auctioning functionality while the portal is being built. The Project Manager should manage these changes only using proper change control procedures.
Project Managers in all different types of industry know one thing for certain. They know that for the Project to be a success it is of prime importance to get the Requirements right. In traditional software projects, managers assume that the Customer is totally aware of his need—i.e., his requirements. So the first job is to get the requirements from the customer. Thus e-projects based on traditional SDLC life cycle will have Requirements Gathering as the first phase.
The reality however is that most Customers in the E-Commerce space rarely have a well-defined Business Model. Project Managers will have to spend inception phase of the project in guiding the customer in discovering their needs. They Project Manager has to help the customer in building a strong business case for the project. In case of e-projects Customers tend to have abstract idea of what they want. The success of E-Commerce Projects comes primarily through strong business plan. The Internet is merely a tool to implement the plan. Technology has obscured the vision of most E-Commerce Portals. The Project Manager should help the customer in focusing on a strong business model rather than on fancy technology.
A strong business plan gives the macro framework for E-Commerce projects to operate on. But technological innovation throws open a large number of possibilities. For example an automotive portal can treat its B2B and B2C customers differentially for the same product offering. User-Friendly screens that are customized to the customer's taste can be a great value addition. Customers relate to an e-business through the web pages with which they interact. A great deal of time is needed to capture these user-interactions. In many cases while designing these user-interactions many of the requirements established earlier will be challenged. Some of them will be eliminated and some enhanced. User-Interface Prototyping using Storyboarding techniques, which build static web pages using Hyper Text Markup Language with hyperlinks to navigate between different web pages, can be a great tool for capturing user-interactions with the portal. These can serve as a tool to help the customer in discovering his exact requirements and capturing his ideas in tangible form. The Storyboards can be subjected to frequent Joint Application Design (JAD) sessions with the important stakeholders to crystallize and give a manifestation to the requirements.
Project Time Management
“Time to Market” is more talked of in case of E-Commerce Projects rather than any other type of projects. While critics may argue time-to-market is critical for all projects, in case e-projects any extra time you take to enter the market will spell disaster for you. If your competitor launches a similar portal before you can then he gets a first-mover advantage; i.e., the mind share similar to market share in case of brick and mortar organizations.
The art of project management is to maintain balance between time, cost and quality. These three sides of the triangle cannot be simultaneously optimized because of their inherent constraints. Studies have revealed that schedule slippage has a more drastic effect on the success of an e-project than cost overrun and defect levels. A McKinsey and Company study reveals that “Products that come to market six months late but on budget will earn 33% less profit over five years. In contrast, coming out on time and 50% over budget cuts profits by only 4% (PM Network 2001).
To crash development and maintenance time in e-projects, you must make use of component-based architecture. Portals need frequent maintenance. Portals have to be dynamic in content and functionality. Only a component-based architecture would aid quick development and maintenance. A well-maintained component library can greatly crash construction and maintenance time while assuring high quality.
Project Cost Management
In an E-Commerce Project we have to ensure even more that we can maximize the value we deliver at the end of the project. The portal needs to have superior features when compared to its competitor. The portal needs to deliver what it is supposed to with minimum defects. The opportunity cost for getting the portal late to the market place needs to be evaluated. The maintenance cost of the portal must be minimized. This is possible only if we employ superior component based architecture. The biggest challenge for Project Manager is to restrict the quantity of rework during the portal development phase. This is possible by preventing scope creep as discussed under Scope Management earlier.
While estimating the Project Cost, the Project Manager has to keep in mind that rework is a fact of software development. Bugs found during testing have to be fixed. Since e-projects have requirement gathering phase that is more of a discovery process there is a large possibility of need of rework as you elaborate your product with every iteration. This may happen due to design flaws or bad coding. Accept the fact that there will be rework and in the initial iterations a lot of them. As you replace stubs with actual components, interface with other systems you will discover lot of areas that need rework and regression testing. Take this into account when you cost your project. You will not have to face a cost overrun. For a well-planned project you will see the cost of rework steadily decreasing with successive iteration rather than ballooning as in the case of waterfall approach.
Project Quality Management
For e-projects to be a success the run-time performance issues such as response time at various loads, scalability is extremely critical. Since E-Commerce portals use commercial components in addition to custom-developed components it is necessary to ensure that performance criteria are met. Modern iterative processes based on architecture-first approach such as Rational Unified Process helps in attacking the performance requirement criteria right at the start (Kruchten 2000). Structural Prototyping is done right at the early stages. This gives early quantified feedback of performance levels.
Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on balance between requirements evolution, design evolution, and plan evolution the overall software quality is achieved (Royce 1999).
Project Risk Management
Project teams take an ostrich like approach to risk management. A risk for which there is no easy solution in sight is ignored. The approach is one of ignoring risk till it hits the project hard. The easier risks are thought of and mitigation approach planned. However after the project has expended lot of effort the risk ignored initially starts looming menacingly. It becomes too late to think of a solution then. There are projects, which select architecture, and technologies ignoring the load the portal will face when it goes live. The risk is pushed to the end. If the portal succeeds in attracting a lot of eyeballs after the initial media blitz, customers get disappointed with the poor response time and they never visit the portal again. The portal even though was successful in pulling crowd fails to retain them. Though functionally it can support the customer, the customer finds the interaction frustrating and will look for an alternative. The Project Manager has to plan for proper load projections and collaborate with the IT architect in achieving it. He must adopt an architecture-first approach to attack critical risk like performance issues. Iterative development methodology (such as RUP) in conjunction with round-trip engineering as provided by modeling languages like UML (Unified Modeling Language) help in weeding out risk at early stage of project life cycle.
Project Human Resource Management
For some reason Senior Management tend to use a sound Technical architect to manage the project. This practice may have arisen from the fact that e-projects employ bleeding edge technology. A Technically sound architect may be in a more comfortable position to understand the complexity of the project and run it smoothly. There is also a feeling that e-projects do not need elaborate software project management since they are typically of short duration. This approach leads to a situation where the Technical Architect takes more keen interest in technical activities like architecture development at the cost of Project Management. There are so many examples where one can see the Project Manager spending fine-tuning the architecture while the project gradually slips out of control with respect to cost and schedule. Using the project manager and architect as the same person will work only on small projects (5–10 people) (Kruchten 2000). For large projects to succeed a dedicated Project Manager is required. Project Manager to double up as the architect will not work either. Deciding on Configurable items to be produced at each iteration needs good understanding of business and technical knowledge. Both these jobs require totally different skill sets. The project will succeed only when Project Manager and the IT Architect collaborate effectively.
Project Communication Management
In case of iterative development using unified modeling language, stakeholders review tangible outputs such as prototypes, architecture, use cases, class diagrams, source code etc at each milestone (Kruchten 2000). This is unlike waterfall model where stakeholders review documents over most of the life cycle and can see the actual system only toward the end of the life-cycle phase.
Iterative development is preferable both to the stakeholders since they do not have to sign off all the requirements right at the early stage of the life cycle within a specified time period. In case of Waterfall model the relation between the stakeholder and the project team degenerate into mutual distrust and makes balancing requirements, plans and portal features difficult. In Iterative model the project team takes the customer view of quality, i.e., “fitness for use” rather than producer's view of quality, i.e., “meeting requirements as per signed off documents.”
Choosing the Right Technology
RAD tools are best suited for building quick and dirty application prototypes. When you build the actual product using RAD tools, the product may not give you the desired performance levels. There is a vast choice in the selection of programming tools to implement the design of the portal. RAD tools greatly reduce development time of code in the short run but may not support component-based development. As a result the code becomes unwieldy, not easily extensible, reusable and maintainable. The code generated may not be optimized and will result in code, which is not scalable, and has response time far exceeding desired values. They can be used as tools for prototyping in the initial iterations as we built a business case for the project. Object Oriented Programming Language like Java gives you code that is highly maintainable, can be used for component based development and can give rise to a library of reusable components that can be used across systems. The end product if supported by a good architecture will be scalable and provide desired performance levels. The choice of a proper Technology platform will influence the Project Managers effort and schedule planning. The Project Manager also needs to take into consideration the learning curve involved for programmers to learn the technology. If there is a steep learning curve involved programmers will have low productivity and high error-rate. This may affect the product quality as well as lead to more rework and construction time. For a new technology platform, the PM may not have initial baseline data for productivity. This may hamper accurate effort estimation.
Conclusion
The paper has focused on the advantage of iterative software development process along with component-based architecture toward successfully managing e-projects. Project Management is crucial for the success of e-projects though they may be technology intensive and short duration. In fact a greater effort of Project Planning is needed but the advantage derived such as attacking risk early, better understanding between stakeholders, more accurate project monitoring, and an end product that meets users need both functionally and by performance parameters more than compensates the additional project planning effort.