Buckle up, project management @ e-speed



The explosive growth of the Internet world left many wondering if old business strategy was still applicable in this e-Business age. The wise few however argued that the Internet was simply an en-abler rather than a new business model. In the end they were proven right. The dot-coms have become dot-gones and those who remained standing were left to pick up the pieces. The one thing that the e-Business era seemed to have succeeded at was forcing organizations to adopt a faster speed of doing business. From quick turnover on purchase orders to faster time to market, customers the world over are demanding speedier delivery of products and services. This phenomenon has single handedly wreaked havoc on the Project Management profession as it left everyone asking: Can proper Project Management standards be followed in an era where project delivery time frames could last as little as two weeks? The answer to that question is a most resounding yes! But, you'd better buckle up and keep your eyes on the road; otherwise you just might end up with one big, massive wreck. Welcome to the world of e-Speed.

Scope of Discussion

The topic of traditional business strategy models versus the new Information Age has been going on for a couple of years. Michael Porter, the father of Strategic Planning, and Lou Gerstner, former CEO of IBM, have been among the leading visionaries in explaining that the Internet age is not about new business models but rather about a new set of enabling technologies. The same is true for Project Management, where many have asked if the new Internet Age requires new standards for managing projects.

In this paper I will describe how a team of experienced professionals, in a delivery environment, can work together to produce project deliverables according to customer expectations on time and within budget, while adhering to Generally Accepted Project Management Principals, resulting in success and repeat business. I will also outline how this is not pure theory but rather is based on a reallife project drawn from an IBM customer engagement.

For confidentiality purposes, I am unable to reveal certain customer specifics such as their name and detailed profile; however, I am able to share that this customer is an Internet startup, owned by a Fortune 500 company, operating as a market integrator in the fi-nancial services insurance sector. For the purposes of this paper I will refer to this company as the Customer.

Characteristics of an e-Speed Project

Prior to initiating discussion on the actual IBM Project Case Study, it would be beneficial to briefly outline the characteristics of an e-speed Project. One might ask what is an e-Speed Project? The term e-Speed is a term that I coined to describe the Project Management Mindset that is required to successfully manage a specific type of e-Business Project. e-Speed is not a prescribed Framework such as PMI's PMBOK® Guide, but rather is an approach that utilizes traditional Project Management thinking, coupled with a strategy to address the specific needs of these specific e-Business Projects. Thus in addressing these needs, it is important to understand the characteristics of projects that require this mindset so that the delivery organization can be better equipped in dealing with their complexity. Often these projects require:

•  Delivering the project solution very rapidly to ensure a quick time to market launch that meets customer expectations.

•  Prioritizing thousands of business requirements associated with development of the desired end solution.

•  Managing multiple subproject teams across organizations, both internal and external to the organization.

•  Administering an iterative development cycle to allow for quick completion of deliverables that can be demonstrated to the customer.

•  Developing a strong change control process that allows the stakeholders to understand the impact of potential changes and react quickly in updating project plans.

•  Establishing a clear and concise set of roles and responsibilities to allow for better management of deliverables and mitigate the risk of confusion and finger-pointing.

•  Creating a project communications strategy that makes everyone aware of issues, progress, and performance in a timely (instant) and consistent fashion.

As it is clear that some of these characteristics are shared by the majority of e-Business projects, the primary difference here is that the e-Speed project is often times a make or break project on which the whole company, in this case the Internet startup, gambles its very existents. As a result the stakes are higher and thus success is demanded quicker. With that, let's take a look at the specific case study within this paper.

Project Case Study

The Customer approached our organization within IBM with the requirement to develop a private e-marketplace that allows for business process integration within the insurance industry. A deal was struck between the two companies resulting in IBM providing Software, Hardware, Internet Hosting, and Development Services in excess of $2.5 Million.

Upon initial review of the project scope and requirements, it became clear that in order to succeed on this implementation, IBM would need to put in place an overall Project Management approach that addressed some key critical success factors. These success factors included:

•  Rapid delivery of the solution

•  Quick requirements prioritization

•  Successful management of multiple subprojects and complex project team organizations

•  Fast completion of project deliverables

•  Strong use of a methodology to plan, track, and correct project performance.

As you may notice, many of the above-mentioned critical-success factors match what I defined as the characteristics of the e-Speed project. So in order to meet these critical success factors, the team set out from the beginning, upon signing the initial contract, to implement a comprehensive project management approach based on PMI's PMBOK® Guide Principles and IBM's Worldwide Project Management Method. Through this approach the team was able to put in place a mechanism for planning, executing, and controlling our overall initiative. The team also utilized various technology tools to build a Project Management system focused on proac-tively tracking performance to correct deviations from our plans. The outcome was a successful delivery of our project resulting in customer satisfaction and repeat business for IBM.

Within the following sections based upon PMI's knowledge areas, I will define the specific context of the project, the many challenges the team faced in addressing these needs, the process that we used in managing the various aspects of the project, some best practices we employed to ensure success, and some lessons learned we gathered as a result of our mistakes. A key focus point that needs to be kept in mind is that without the team's active involvement and understanding of the Project Management process, the project would have been doomed to failure.

Project Integration Management

Context: The Customer, an Internet startup, is a company whose primary business is providing ebusiness-enabled communication between insurance agents and carriers. The Customer's business need was to implement a solution that would allow the company to provide insurance agents, brokers, and clients with the ability to evaluate and receive insurance coverage and financing from a variety of insurance carriers. The project solution was designed to address four major process areas related to insurance quoting and processing of new business.

Challenges: The complexity of the requirements related to these processes and the need to design a solution that takes into account future requirements made the planning and execution of the project highly difficult.

Process: In addressing these intricate requirements and challenges, the project team defined an overall phased approach to managing this project, which included:

•  Proposal—development of the contract and statement of work

•  Concept—defining customer objectives and business needs

•  Solution design—requirements and specifications

•  Initiation—project kickoff

•  Planning—project plans and baseline development

•  Execution—coding, implementation, and deployment

•  Controlling—change control management

•  Closing—contract and administrative closeout.

This process allowed for a clear and methodical approach in building the project baseline and executing according to plan. This approach also made it easer to manage needed changes. By necessity this project required making changes to the scope, time, and cost. So rather than trying to prevent these changes and failing, the team determined that it was more important to manage them.

Best Practices: Each project has successes and failures; however, ultimate success of a project, in some measure be defined by the ability to crystallize the best practices that the team either utilized from previous projects or those practices that were created as part of the project effort. As related to the IBM customer engagement project the following describes some of those best practices followed within Project Integration Management:

•  The team utilized PMI's framework on the PMBOK® and IBM's internal methodology in customizing the management of the project to the needs of the delivery organization and the customer.

•  Developing a process to capture lessons learned from the beginning of the project so that the team could learn from the mistakes committed in early phases and adjust performance accordingly.

•  As simple as it sounds, holding an official closeout meeting and asking The Customer for an official signoff on deliverables provides the team with a sense of completion and accomplishment. Lessons Learned:

•  Involving the Project Manager during the sales process would have mitigated some of the risks identified during planning.

•  Holding a transition meeting between the sales team and delivery team would have improved the understanding of customer expectations and corporate promises, allowing for seamless execution.

Project Scope Management

Context: The project scope was to design, develop, test, and assist in the transition into production, a solution that consisted of a GUI system, process flow, business rules engine, and messaging. The major requirement was that this solution was to be based on Internet technologies. The project deliverables consisted of solution code for various system components, project management documentation, system documentation, testing results, and signoff documents.

Challenges: At contract signing, much of the scope was still not well defined. This required a systematic approach to define, refine, and prioritize requirements.

Process: As part of the contracting process the team clearly defined the deliverables required for completion of the project scope and outlined a detailed process for the submission, review, and approval of these deliverables. A configuration management process was implemented to ensure that deviations were managed appropriately. Project reviews were held to discuss deliverable progress and changes.

Best Practices:

•  Using a systematic approach to defining and prioritizing requirements based on IBM's requirements and specifications guidelines and processes. This resulted in better customer expectations management.

Lessons Learned:

•  Divide “deliverables” into work products and deliverables. Work products are items that must be completed to ensure successful delivery of the project including project charter (SOW), requirements, project plans, designs, project control book, etc. Deliverables are part of the physical product/service to be delivered to the customer including program code, instruction manuals, etc. This could allow for eliminating some confusion related to delivery.

Project Time Management

Context: As with many projects that share these characteristics, The Customer's major driver regarding the delivery was speed. They needed the solution as soon as possible to ensure that they met business commitments with clients.

Challenges: Tying project delivery to the business commitments submitted to customers meant that there was little flexibility in managing time changes. As a result, prioritization of deliverables became very critical to the process.

Process: The steps taken to develop a schedule baseline were initiated by a review of the contracting documents and developing a work breakdown structure (WBS) that identified the deliverables of the project. The WBS was then used to outline all the tasks required for the completion of the deliverables and work products as well as the time frames, durations, and resources needed for each task. The schedule was then reviewed in conjunction with the SOW and contracts to ensure alignment from a budgetary perspective. The baseline was completed and published for the team's review and buy-in to enhance its chances for success.

Best Practices:

•  The ability to develop the WBS enables the whole team to truly understand the scope, and thus the necessary activities to completing the deliverables.

•  Tracking hours to specific activities within the project enabled better assessment of project performance.

•  Building one project schedule that encompassed all the subpro-jects enabled a global view of the project.

Lessons Learned:

•  If we had checked in IBM's intellectual property databases we would have found schedule templates that could have been utilized in planning activities.

•  Not every individual has access to scheduling software. The ability to publish the schedule in an electronic format that is readable was an important need that the team missed.

Project Cost Management

Context: As the products and services provider our organization was required to assist The Customer in developing its cost baseline based on its hardware, software, services, and hosting. Evaluating project estimates and communicating with the sales team to ensure they were in line with the overall project plan was of critical importance.

Challenges: Additional complexity in the estimating came because these costs were generated from multiple internal and external organizations the majority of whom were billed for through our organization.

Process: Using established IBM business standards, tools, and systems, was of great importance to the project team's success in effectively managing overall project costs. Each team member and organization, both internal and external, was required to submit weekly status reporting that included cost expenditures.

Best Practices:

•  Requesting that each individual provide their weekly status report, which included their hours worked and travel expenses facilitated reconciliation with the corporate invoicing systems.

•  Tracking costs based on project activity allowed us to better manage tasks and track progress.

Lessons Learned:

•  In developing the cost estimates for our suppliers we did not take into account the services cost of resource band as compared to experience level. As a result, the team had to pay more to bring in a more experienced individual thus eating into our profit margin.

Project Quality Management

Context: In many e-Speed projects, project teams tend to fall into the trap of not designing the quality process into the Project Management approach as a quality assurance framework but rather implement it as a quality control measure. This was one major pitfall that our team wanted to avoid. The rapid development approach made this goal even harder due to the parallel activities of competing deliverables.

Challenges: The fact that there were several predefined milestones and cost baseline parameters made managing the project to the established quality standards more challenging.

Process: By utilizing a source code control system, we were able to implement a configuration management process that controlled the solution quality. Holding periodic quality reviews both internally and with the customer ensured a continuous focus on the quality standards needed to achieve results. Project Management quality standards were established using IBM's internal Project Management methodology.

Best Practices:

•  The use of existing IBM processes and infrastructure as opposed to fighting organizational standards enhanced team performance.

•  The ability to distinguish between quality standards for managing the project, versus quality standards in producing the product helped the team understand the necessity for both resulting in a better quality assurance process.

Lessons Learned:

•  If the Project Manager is unable to adjust scope, cost, or time, due to a change in the project or a risk realized, the only option is to let quality slip. That was a tough lesson to initially discover, but a very valuable one as the project progressed.

Project Human Resource Management

Context: The broad scope of the project required that our team engage multiple organizations both internal to IBM and external to the organization to provide needed subject matter expertise in the development of the deliverables. Managing the on-boarding, orientation, performance, and resource morale was of utmost importance.

Challenges: In addition to having to deal with multiple organizations, our team was also required to interact with a third-party solution provider's resources and the customer's subcontracting organization. Managing the expectations of these individuals and the agendas of their organizations was needed to ensure avoiding major barriers in implementation.

Process: During the planning process, a framework was put in place that outlined all the needed roles for the project as well as the detailed responsibilities required for delivering the various components of the solution. In addition, a resource plan was developed that outlined resource needs based on the timeline identified. Due to the fact that resources were not all procured at the same time, an orientation plan was necessary to ensure a quick on-boarding process thus having productive resources. The team utilized a variety of Lotus Notes teamrooms in keeping its documentation and communicating with each other.

Best Practices

•  Developing a timeline of resource needs was critical to ensuring “just-in-time” availability of resources.

•  Defining a process that allowed the Project Management team to dismiss resources that lack the necessary skills to accomplish their assigned tasks.

Lessons Learned:

•  IBM's complex organizational structure and process made the challenges faced by the project team even greater. Tapping into the knowledge and network of seasoned team members helped mitigate this risk.

•  The team initially did not have a strong mix of senior and junior resources.

•  There was a need to establish a process for awarding performance.

Project Communications Management

Context: The main requirement in this area was to ensure that communications were conducted effectively and efficiently. This meant that information was to be distributed quickly, consistently, clearly, and accurately. Utilizing customized templates for communicating issues, status reports, change requests, and risks was a critical success factor on the project.

Challenges: Due to the size of the team, communicating the proper information accurately became a constant issue. As a result the team had to continually be reminded of the agreed upon communications process to ensure consistency.

Process: During the initiation phase of the project, a communications plan was developed which outlined what was needed to be communicated, to whom, by whom, at which times, by which mechanisms, and through which media. As the Project Manager, I was the primary point of contact on all customer communications and I worked with the customer Project Manager to ensure that communications were exchanged clearly and accurately. Periodic Project Management team meetings were held to review communications and to discuss progress with key customer executives. The communications process was published and explained to all project team members whereby deviations from the plan were addressed immediately to ensure that problems did not recur. The team implemented a project collaboration site on the Lotus Web-based collaboration site Quickplace and utilized this tool as an instantaneous communications and feedback tool.

Best Practices:

•  The utilization of an internal teamroom and an external Quick-place collaboration site. This served as an important communications and documentation link.

Lessons Learned:

•  Develop a team lexicon of common Project Management and business process terminology to increase the chances of meeting time, cost, and scope requirements.

Project Risk Management

Context: Project risks on this effort ranged from brand new and un-proven technology to resource issues surrounding skill levels. This is unfortunately a common characteristic of e-Speed projects and while there is very little in the way of avoidance strategies, strong mitigation skills were required to maintain the project on track and within budget. De-scoping becomes a real life option as part of these mitigation strategies.

Challenges: The customer did not display a clear understanding of risk mitigation strategies. Educating the customer team on the process required focusing on how the risk plan was to be developed and how it would be used.

Process: Risk assessments were held to determine risk events during the project as well as to quantify these risks and determine how to best address them through the development of a risk response strategy/plan. An IBM risk template was used to document risks and response plans. Risk assessments, which were held at appropriate intervals, started during sales qualifications and continued through initiation, planning, execution, and closeout.

Best Practices:

•  Conducting risk assessments frequently enabled our team to identify potential risks early on and determine mitigation strategies.

•  Maintaining a simple process for identifying, quantifying, and mitigating risks helped ensure everyone's buy-in and support.

Lessons Learned:

•  Conduct additional risk assessments with the customer to better explain their responsibilities related to mitigating risks.

Project Procurement Management

Context: IBM's focus on procurement dealt with the purchase and resale of the third-party software and services to the customer. This required the signing of complex agreements with both suppliers and the customer to ensure that proper costing and revenue targets were taken into consideration.

Challenges: Third-party provider resource skills were not at the level needed to allow for the necessary expertise. A detailed analysis revealed a lack of alignment between this provider's offering and the customer's needs.

Process: Many of the processes followed in this area were IBM predefined processes utilizing proprietary systems. Up-to-the-minute reporting through these systems were available to track costs and revenues.

Best Practices:

•  Designing a contracting process that protected the organization and the project team. The team utilized document templates such as the SOW to communicate with supplies their roles and responsibilities.

Lessons Learned:

•  To ensure that services suppliers provide resources with the necessary level of skill to get the job done in accordance with the contract.

Project Results

The overall results of this project were as follows:

•  Expectations management ensured that satisfaction was attained. The Customer's request for follow on business indicates success.

•  Team responsibilities were outlined early. Individuals maintained a good work ethic and were rewarded adequately. Several team members received IBM awards.

•  Project business objectives were met, however, minor scope modifications were required based on customer business needs.

•  Strong communications on progress helped ensure everyone was aware of project status. The team met its agreed upon time frame.

•  Project revenue and profit targets were met, with a variance of no more than 10% based on the scope and approved change requests.

In the end, the ultimate success for an organization is its ability to learn from its successes and mistakes by capturing its experience in its intellectual property archives, whatever they may be. The following section provides a glimpse as to why the above-mentioned project and many like it share some success characteristics.

Critical Components of a Successful e-Speed Project

Upon final review of this concept one might ask what are the critical components needed to ensure success on an e-Speed Project. While there are some differences between e-Speed needs and traditional projects, the bottom line is that a successful project is a successful project. A project that meets its scope, time, and cost parameters while delivering within quality standards and meeting customer expectations is a successful project. Here are some of the components that one can look for in a successful e-Speed Project:

•  Quick decision-making. The only way is to delegate decision making to the Project Manager and empower them to act on behalf of the organization.

•  Clearly established business objectives and a clear understanding of business drivers.

•  A plan that breaks deliverables into achievable small milestones.

•  Define requirements, prioritize them, and negotiate with the customers on which ones are necessary and which ones are gold plating.

•  Utilize a proven Project Management framework such as PMI's framework outlined in the PMBOK® Guide as well as a proven methodology that builds on the framework.


Initial observation of e-Speed projects may lead an individual to believe that they require their own special brand of Project Management. However, as I hope I have been able to demonstrate throughout this paper, even though there are some nuance differences between traditional projects and e-Speed Projects, many characteristics are shared. The primary challenge in an e-Speed project is “Speed.” The Internet world demands fast action, decision-making, and execution. A project team's ability to create such a dynamic environment enables the delivery organization to address customer requirements in a satisfactory fashion. This requires the qualified Project Manager to realize the characteristics of these projects, then implement the critical components for success based on best practices and lessons learned, such as those outlined in this paper.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA



Related Content

  • PMI Sponsored Research

    Digitalization as a Game Changer in Project Stakeholder Management member content open

    By Kier, Christof | Huemann, Martina This research work aims to discuss contemporary project stakeholder engagement and examines how digitalization shapes and affects the field.

  • Project Management Journal

    Using Principal–Steward Contracting and Scenario Planning to Manage Megaprojects member content locked

    By Turner, J. Rodney Megaprojects are complex, but people use constructs inappropriate in complex situations for their management, particularly contractual arrangements.

  • Project Management Journal

    A Dynamic Capabilities Model of Innovation in Large Interfirm Projects member content locked

    By Steen, John | Ford, Jerad A. | Verreynne, Martie-Louise The time-bounded nature of large interfirm projects and technical interdependencies constrain innovation.

  • PM Network

    A força do 5G member content open

    À medida que a adoção e implementação do 5G aceleram, o impacto econômico da banda larga ultrarrápida e onipresente está entrando em foco.

  • PM Network

    O futuro da aprendizagem member content open

    By Fister Gale, Sarah Mais de 1 bilhão de crianças em pelo menos 185 países foram afetadas pelo fechamento de escolas relacionado à pandemia global no ano passado.