Beginning at the ending

Abstract

Information Technology (IT) projects can be difficult to complete on time, on schedule, and within the original proposed scope. In addition to facing the challenge of new or changing technology, Project Managers often have to deal with vague expectations, demanding deadlines, faulty or unstable requirements, and unrealistic budgets. This paper will review lessons learned from implementing a project initiation process for an Information Technology organisation. Implementation of this process resulted in an improvement of project successes from 75% to nearly 100%. This paper will address the typical problems encountered in Information Technology projects and will demonstrate how a project initiation process, when executed properly, will increase the project's chance of success. This paper will introduce processes and templates which can be used for initiating Information technology projects. The paper will conclude with factors for success derived from the implementation of these processes.

Introduction

“Pooh looked at his two paws. He knew that one of them was the right, and he knew that when you had decided which one of them was the right, then the other one was the left, but he never could remember how to begin.” (Hoff 1982, p. 12)

The beginning or initiating phase for an Information Technology Project is extremely critical. While projects in other fields also require effective beginnings, IT projects introduce additional complexity because of knowledge and technology gaps often inherent in the products or services to be changed or built. Additionally, IT projects introduce gaps in expectations between project stakeholders leading to faulty planning decisions which, in turn, lead to faulty requirements, deadlines and budgets. Per the CHAOS report produced by The Standish Group, more than half (53%) of the IT projects surveyed in 2004 were over schedule, over budget, or short on promised features and functions (or per The Standish Group, “challenged.”) (2004 Third Quarter Research Report, 2005).

The Project Initiation process proposed in this paper is based on the premise that the probability of success will increase by more clearly defining the vision of the end product or process to be produced by the project. In The 7 Habits of Highly Successful People, Steven Covey teaches us to “begin with the end in mind.” Covey states that this habit is “based on the principle that all things are created twice. There's a mental or first creation, and a physical or second creation to all things.” (Covey 1989, p. 99). The Project Initiation process proposed in this paper leads to the first creation of the product or process. With this first creation as the foundation, the parameters of the project can be more clearly defined and managed thereby allowing for the successful execution of the second creation, the final product or service.

Another factor for success is not beginning the execution of the work until the planning (through the Initiation Process) has been completed. In his book, West Point Leadership Lessons, author Scott Snair recommends that a manoeuvre or operation (such as a project) should not “go forward unless your logistics are in order. Once you know the extent of the task, have plans in place for supplies, transportation, human resources, etc. before you get started. In every one of these areas assume that planning as you go along will mean trouble.” (Snair 2004, p. 96)

While most of the findings in this report are based on documented lessons learned in the installation of a Project Initiation process in one organisation, it is my belief, based on experience, that similar results may be obtained in any organisation conducting IT projects.

Beginning at the Ending: Results

Success Rate

Prior to the implementation of the Project Initiation process, success rates for projects were determined by measuring actual costs and schedule completions against the original targets for schedules and cost budgets. Adherence to scope was not measured but outstanding customer issues at project closure could cause a project to be recorded as problematic. Based on these three criteria (adherence to schedule, cost, and quality/scope objectives), the annual success rate was determined to be 75%, meaning that 25% of projects were measured as challenged or problematic. Within the 25% category were a few projects that were abandoned while in some phase of execution; these projects were of concern for two reasons: one - customer dissatisfaction and trust in IT to execute complex projects, and two – throw-away expense or lost investment in resources spent on those projects.

Harold Kerzner, in his book, In Search of Excellence in Project Management, states that success is defined in “terms of five factors:

• Completed on time
• Completed within budget
• Completed at the desired level of quality
• Accepted by the customer
• Resulted in customer allowing the contractor to use the customer as a reference.”

Kerzner also states that “project managers and their managers now accept that project quality (and project success) is determined by the customer not the contractor.” (Kerzner 1998, p. 25).

The Project Initiation process allowed a foundation to define success per the five criteria noted by Kerzner. Within 12 months after implementing the Project Initiation process, the annual success rate improved to nearly 100%, the only exceptions being a few low priority, low cost internal projects with minor variances. Post implementation reviews were also conducted with the end customers of the projects to validate project successes.

Estimating

Prior to implementation of the Project Initiation process, estimates were primarily performed by knowledge experts within the Information Technology organisation. The estimates were only as good as the estimator's extent of knowledge of all the factors affecting the project. Often, the estimates did not address total costs. Occasionally, some projects were started without any formally stated estimates. On those projects where an estimate was required prior to an investment of resources, the estimates took longer to complete than required or expected.

Estimating accuracy improved dramatically due to the implementation of the Project Initiation process. The process also introduced two concepts which contributed directly to the improvement of estimates:

• Project initiation checklists were used to ensure completeness of estimates (thus removing the dependence on a few knowledge experts)
• A Project Discovery phase was added – this was a brief project assessment used to produce a Rough Order of Magnitude estimate which could be used to make an investment decision early in the project life cycle. On large projects, the Discovery phase allowed for additional time to investigate requirements and produce a more accurate estimate.

Scope Management

Before the Project Initiation process, project scopes were not defined for all projects and were often missing components or were ill defined. Scope definitions were not defined consistently in format or content and varied from project manager to project manager.

The Project Initiation process improved the quality of scope management in three areas:

• Completeness of content (resulting from internal scope reviews)
• Consistency of format (through the use of templates)
• Scope Change Management (improved scope baseline allowed for tighter change management)

Project Cancellations

Project cancellations, defined as projects cancelled in the execution phase, were also drastically reduced due to the newly implemented Project Discovery phase. Due to the Discovery phase, projects which did not make economic sense were now screened and cancelled in Discovery prior to the investment of resources in the execution of the project. Prior to the new processes, resource losses on cancelled projects were not tracked, but were not trivial.

Customer Satisfaction

Customer satisfaction improved due to a number of factors:

• Involvement of the customer in the Project Initiation process.
• The ability of the customer to control project expenditures earlier in the project process and to make significant “go/no go” decisions in the Discovery phase prior to making significant investments in the projects.
• Improved baselines for cost, schedule and scope allowed for improved change management and information reporting.
• Scope baseline allowed for improved and more accurate acceptance of final project deliverables.
• Post-implementation reviews conducted with the customers (these were objective reviews conducted by someone other than the Project Manager).

Although not tracked, and difficult to quantify, the number of customer complaints shared with the managers of the project managers were also reduced significantly.

Use of IT Resources

After the implementation of the Project Initiation process, IT resources were more effectively managed. The primary factors contributing to the improvement included:

• Tighter control of resources used to estimate new projects.
• Processes for estimating allowed for more efficient delegation of estimating resources.
• Resource waste due to cancelled projects was reduced drastically.
• Improved scope definition allowed for improved planning and forecasting of resources.

Problems – Prior to Implementation of the Initiation Process

Summary

This section briefly addresses some of the common problems encountered in an IT organisation prior to the implementation of a structured Project Initiation process. It includes observations not just from this organisation but from my experience and exposure to other IT organisations serving non-IT businesses.

Scope Definition and Management

Typical problems with Project Scope included the following:

• Missing scope – some projects were initiated without any formal documentation. These projects were, of course, difficult to manage and extremely difficult to obtain complete project acceptance of project deliverables as these were not formally defined.
• Incomplete scope – projects with incomplete scope resulted in complaints from both customers and internal departments (internal stakeholders) affected by the product or service to be produced. Per A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) (2000), project stakeholders include those individuals or organisations which may be negatively affected by the result of project execution or completion. (p. 16). Internal IT departments such as the Help Desk, Customer Training, Computer Operations, and Technical Infrastructure (to name a few) were often overlooked in the development of an estimate yet these departments could affect the final scope and costs of the project and the product.
• Scope change control – without clearly defined scope statements in the initiation process, managing change to the scope and controlling scope creep was difficult if not impossible in some cases.

One significant symptom of poor scope definition and control is what I call the “never-ending project.” A never-ending project is one that is usually started in good faith but once started gets off track and then becomes difficult to stop due to potential customer service problems. These type of projects create a “lose/lose” situation for both the customer and the provider organisations. The customer is usually not satisfied with the project management service and the providing organisation usually ends up losing financially.

Lack of User Input

Lack of user input is a major contributor to challenged projects. Symptoms of lack of user input include missed expectations, poor scopes, missing design elements, incomplete definitions of work, and poor planning. Lack of user input can occur through the following:

• Poor or little communication with the Project Sponsor.
• Lack of or poor communication between the Project Sponsor and the sponsoring organisation's stakeholders.
• Lack of or poor communication between the Project Manager (or Project Team) and the stakeholders.
• A poorly defined or vague Vision statement.
• Vague or lacking user requirements.

User input is critical at the start of the project because as the PMBOK^® Guide (2000) states, “the ability of the stakeholder to influence the final characteristics of the project's product and the final cost of the project is highest at the start” of the project. (p. 12).

Inconsistent Planning and Financial Management

Inconsistent planning leads to poor resource management, which, in turn, leads to poor financial management. Without clearly defined project plans for all projects in the portfolio, resource forecasting becomes almost impossible. Poor resource forecasting not only affects the cost management for individual projects, but also affects the cost management of resources of the IT and other stakeholder departments. This can become even more frustrating for managers in a matrix organisation, where resources are assigned to both projects and functional responsibilities.

Lack of Trust

Probably more damaging than any other aspect is a lack of trust that can occur between a customer and its provider of IT projects due to some of the other symptoms already noted. A lack of trust can lead either directly or indirectly to financial losses on the part of the provider. A lack of trust can force more rigid contracts, approvals, and documentation. An organisation can become more effective by establishing higher levels of trust. Per Harold Kerzner, some of the benefits of increased trust include long-term contracts, repeat business, sole-source contracts, reduced documentation, and lower sponsorship levels. (Kerzner 1998, p. 199).

Lessons Learned

Summary

In reviewing the reasons for the improvement of project successes from 75% to nearly 100%, the following are considered the key factors producing these results:

• The enhanced Project Initiation processes accounted for nearly 70% of the improvement. Executive support was critical to the enforcement of the discipline required to achieve these results and to maintain consistency. A small Project Management Office (PMO) was used to provide coaching to the project managers and to ensure consistent application of the processes.
• Change Control processes accounted for another 20% of the improvement. A Change Control process was implemented concurrently with the Project Initiation process. The Change Control process allowed for the formal recognition of changes to schedule and budget when scope changes were requested.
• The final 10% of the improvement can be attributed to the management team focus on projects and project management. Project portfolios were reviewed by the management team at least once a week. Additionally, all new projects were reviewed by the IT management team prior to review with the customers or sponsors.

Lessons Learned: What Worked

Enforced Initiation Process

Backed by Executive Management along with commitment from the functional managers, the Initiation Process was effective because it was enforced in the organisation. All projects greater than 80 hours were subject to the Project Initiation process. This enforcement led to a consistent packaging of the project proposal with respect to both content and format. Additionally, confidence (and trust) in the project proposals improved within the IT and customer organisations.

PMO Reviews

The Project Management Office led the following reviews:

• All new projects. This led to improved estimating as all new Rough Orders of Magnitude (ROM's) and Statements of Work (SOW's) were reviewed, validated, and checked for consistency and completeness.
• Weekly portfolio reviews.
• Change requests.
• Post-implementation reviews with customers.

Project Initiation Templates

Initiation templates were implemented for the Discovery and Initiation phases. These templates were developed by the PMO and all project managers were trained on the templates and associated processes. These templates worked because they were easy to use and served as a solid tool for communicating project scope, planning, and estimates.

ROM and Discovery Concepts

The Discovery phase and the ROM concept proved effective because they allowed a brief review of projects prior to the investment of significant resources. Estimates were usually based on similar efforts or were top-down using expert input. Valuable resource time was minimized by keeping the Discovery phase short along with a brief review.

New Project Checklist

A New Project Checklist was introduced into the IT organisation. This checklist was effective because it helped define the scope of a new project and led to more complete estimates.

WBS and Bottom-Up Estimating

Estimates were further improved through the use of Work Breakdown Structures (WBS) and bottom-up estimates. Training was required to ensure consistent development of the Work Breakdown Structures. On larger projects, the development of the WBS was facilitated by a member of the PMO. One side benefit of the WBS process was the ownership resulting from the parties contributing to the estimates.

Lessons Learned: What Didn't Work

Stringent Methodology

A stringent methodology was considered unnecessary and counterproductive. Executive Management and the PMO supported a coaching model for the PMO. The PMO coached project managers through the processes and provided direct support when required.

Automated Development Tools

Several automated code development tools were tried for the larger projects, but for this organisation were considered unnecessary.

Expensive Project Management Tools

Various Project Management Tools were evaluated for portfolio management and resource management, but determined that they were not financially justifiable. Tools were limited to Microsoft Office and Project products which proved effective for this organisation.

Templates by Project Size

Although templates by project size were attempted, this proved to be an unnecessary measure. The same templates were used for all projects – this did not cause any issues with the project managers.

Processes and Templates

New Project Checklist

A New Project Checklist was developed and implemented. The primary purpose of this template was to provide a set of questions which were then used to frame the project scope. All functional departments were provided an opportunity to provide input to the checklist. The template was owned and updated by the PMO.

ROM and Discovery Process

The Rough Order of Magnitude (ROM) and the Discovery process were used to screen projects and to determine those projects that were “bigger than a bread basket.” A template was developed for the ROM and included the following features:

• Provided a top-down or analogous estimate
• Usually provided an estimate in ranges
• Usually used to request approval to proceed with a formal statement of work

Statement of Work

A Statement of Work template was developed and, at minimum, contained the following components: Vision Statement, Objectives, Scope, Assumptions, Constraints, Risks, WBS, and Estimates (schedule and budget).

While all of these components are important, I believe that the Vision statement is the most critical. Developing the Vision Statement is a critical exercise in communications between the Project Sponsor, the Project Manager, and the Project Stakeholders. As Winnie the Pooh says, “Before beginning a hunt, it is wise to ask someone what you are looking for before you begin looking for it.” (Winnie the Pooh quotes, 2005)

After the Vision, the Project Scope requires focus on the part of the Project Manager and the project team. “Project scope is a definition of the end result or mission of your project – a product or service for your client/customer.” (Gray & Larson 2003, p. 100). Equally important to the definition of what is to be included in scope is the documentation of what is excluded from the scope of work.

Ending at the Beginning – Success Factors

Post-Implementation reviews were held for all completed projects and helped validate the following key success factors for Information Technology projects:

• Customer/sponsor involvement – the more involved the customer and sponsor were in the definition of the Project Vision and project requirements, the greater the chance of success.
• Problem definition – the ability to clearly state the business problems to be addressed by the project was also considered key to success. With new or unproved technology, this problem definition became even more critical.
• Assessment of risks – risks were often overlooked prior to the implementation of the new project initiation processes but risk assessment becomes critical in determining project success, especially when a new or unproven technology is to be employed.
• Skill levels and experience – a proper assessment of skill levels and experience with the business processes and the technology was also considered a key success factor.
• Project Management skills and experience – as the project managers became more comfortable with the new processes, the project success rate improved and trust in the organisation increased.

In conclusion, I would like to offer that while Information Technology projects do present risk, there is an answer and it a low-cost easy-to-implement solution: try beginning at the ending.