Project management has thousands of definitions--some of them useful, most of them overcomplicated. Since my background is in mathematics, I define project management as Expectations Set = Expectations Met.

Studies of systems development projects offer some alarming statistics. According to the Standish Group, $275 billion is spent in the United States annually on over 200,000 software development projects--roughly 30% of which become "shelfware" and over 40% of which result in time and cost overruns. No one would claim that the shelfware projects are successful, but what about the projects that eventually do deliver, but at a higher cost? Are they also failures? Well, it depends.

In a dynamic environment, project managers and sponsors need to continue to set and reset expectations--monthly, weekly, sometimes daily--to fulfill the equation Expectations Set = Expectations Met. If expectations are reset regularly, sponsors can be entrenched in the decision-making process and, therefore, cannot be surprised by changes in deliverables, cost, and time projections.

Project Scope

A common device for predefining the boundaries of a project is the "project scope." Its purpose is to do all of the following:

• Discuss business case and requirements
• Conceive and draft a solution
• Clearly define and contain the project
• Group deliverables into priorities and phases
• Limit the shared project risk
• Determine project roles
• Estimate the work effort involved

This typically involves face-to-face meetings at the project sponsor's site, followed by offsite creation of deliverables such as these:

• Executive overview (need, solution, costs, dates)
• Proposed solution (preliminary architecture and design)
• Priorities, phases, project plan (Gantt chart), resource plan
• Time and cost estimates
• Project charter (assumptions, meetings, change control, acceptance, post-delivery support plan, etc.)
• Risk assessment
• Prototype of the application (proof of concept, visual interface, performance, etc.)

The project scope constructs and documents the meeting of the minds to which contractual agreements might later refer.

Estimating Models

Everyone wants to know the future, especially project sponsors. Before approving a project, the sponsors always wants to know what effort will be expended, so they can decide if the investment is justified by the project's business case. In other words, is there enough bang for the buck? One can never fully realize the effort required until after the project is complete, but there are techniques for estimating the effort in advance. Four main models are used frequently in the "real world":

• Ambient Flow Digital Saturation
• Extrapolation from Legacy System
• Extrapolation from Prototype
• Detailed Project Plan (a.k.a. WCBS)

Ambient Flow Digital Saturation

This model (aka wet finger, lift to breeze!) is used more often in our industry than we care to admit. In the same category is the Digester Sensory model (aka gut feeling!). These techniques often prove reasonably accurate if the owner of the finger or gut has sufficient experience with very similar projects. However, they should be used in combination with more scientific and quantitative methods. A survey conducted by Robbins-Gioia, Inc. showed that 90% of project managers often underestimate project size and complexity. I'd bet most of them rely solely on this weakest of models.

Extrapolation from Legacy System

Many development projects are intended to replace an existing system. Analysis of the legacy system is done to arrive at broad statistics. For example, the legacy system might employ 200 database files and 1,000 programs. Those with intimate knowledge of the legacy system might suggest that 30% are considered simple, 50% are moderate, 15% are complex, and 5% are very complex. By studying a small subset of the legacy system's files/programs, the estimator might determine that a simple object will require one day of development effort, three days for moderate, etc. One can then multiply and add to arrive at the total person-days of development effort estimated. This method relies heavily on the guidance and judgment of the current system experts. However, it does provide a ballpark estimate with minimal effort.

Extrapolation from Prototype

Prototypes are small, semi-functional chunks of a system used to explore or prove a particular concept. Visual interfaces are often prototyped to show end-users how their system might ultimately look, or weighted algorithms might be built to feign and test performance loads that may result in the final system. However, prototypes can also be used for estimating. A small subset of the application is built that reasonably represents a cross-section of the technologies and complexities of the final system. If the prototyping requires one person-week of effort and is judged to represent 2% of the future system, then the full development effort is estimated to require 50 person-weeks (1 week / 2% = 50 weeks). As with an Extrapolation from Legacy System, this method gives a ballpark estimate in a short period of time, but it depends heavily on the judgment of the prototype's relative scope. If the prototype proved to represent only 1.25% (instead of 2%) of the full system, the estimate would be out by a whopping 30 weeks! This estimating technique also relies on another leap of faith: that the economies of scale derived from developing a large system perfectly cancel the integration complexities.

Detailed Project Plan

A detailed task-level project plan is eventually required during the construction phase of a project as a mechanism for assigning scheduled--and often interdependent--units of work to project team members. However, such a project plan is also a highly reliable estimating tool. With an estimate of each task, one can easily tally the estimates to arrive at a total. It's that simple. The hard part, of course, is ensuring that all tasks are well-defined and none are overlooked--which can only be achieved via a detailed project scope. What can make this estimating method supremely accurate is if (big if) each task is estimated in isolation, blindly, without anticipating how the estimates will sum to the overall project estimate. Although this method requires the most effort, it is consistently the best predictor. Besides, a granular project plan is eventually required anyway, right?

Change Control

OK, so our project scope and estimating has resulted in a preliminary design and Granular Project Plan. We have established the "meeting of the minds." We can now rest easy, right? Absolutely...as long as there is no post-scope discovery and the sponsor's business-driven requirements remain identical throughout the life of the project. In other words, fate has kindly agreed to allow the project to run in a vacuum, completely detached from reality. If you are a project manager who regularly finds yourself in that situation, there's no need to keep reading--you've found Nirvana! However, if you're on this planet--or at least in a near-Earth orbit--please stay with me. As the expletive-free saying goes, "stuff" happens. When it does, here's what to do:

• Identify change (in or out of scope)
• Generate a formal request document
• Estimate the estimate (it might take five person-days just to understand the request and conceive a solution)
• Assess the impact of the change (time, cost, resources, etc.)
• Get the sponsor to approve, reject, or defer
• Absorb change into project plan
• Maintain separate accounting

Paramount to the above procedure's success is determining who can do what. Who from the sponsor's group can request changes? Who documents the change? Who has the authority to approve the proposed solution to the change and its estimated impact? These authorities need to be pre-defined and documented, typically as part of the Project Charter and perhaps in contracts as well.

As with anything operational, implementing change control requires documents and workflow. Change control documents vary, but two basic types are required: a change request document and a change log.

A change request document should capture the following:

• Change ID, requestor, requested date
• Priority, due date
• Brief description
• Detailed description
• Evaluator, evaluation date
• Estimated effort
• Required resources
• Task dependencies
• Estimated impact on delivery schedule
• Approver, approval date, signature?

A change log is often used to provide a snapshot view; it should include these items:

• Change ID, requestor, requested date
• Brief description
• Priority, due date
• Evaluator, developer, tester
• Estimated effort, completion date
• Various statuses, flags
• Actual effort, completion date

Change workflow can be as formal and sophisticated as agreed is required:

• Movement of actual paper bearing hand-written signatures
• Email, fax
• Spreadsheet log with status
• Movement of change requests from one directory to another (e.g., changes to be estimated, changes to be approved, changes to be scheduled, etc.)
• A computerized system (ideally, linked with the project plan)

Risk Control

During the project scope phase, an assessment of risk is often performed to highlight concerns significant enough to jeopardize the project's ultimate success. Some typical areas of risk are these:

• Estimating model used
• Degree of sponsor commitment and involvement
• Experience versus breaking new ground
• Completion criteria, attainable goals
• Project team motivation and skill

It is important not only to identify each element of risk, but to quantify its probability and downside potential. Risks should be openly discussed with the project sponsor (Expectations Set). Monitors and prevention mechanisms should be established, and plans should be drafted to mitigate the risk should it arise (Expectations Met).

Project Meetings

The project equivalent of sailing's keel and gyroscope are regular project meetings. They ensure that the project remains on course. In addition to ad-hoc sessions between project team members (for design walk-through, peer reviews, brainstorming, task assignments, etc.), most projects merit a standing weekly meeting between the project team and the sponsorship team. As with all meetings, a minute-taker and chairperson should be assigned, and an agenda should ideally be delivered in advance so all parties can adequately prepare. Typical project meeting agendas should include a review of the following:

• Accomplishments since the last meeting (completed tasks, issues resolved, etc.)
• Tasks in progress or soon to be started
• Resolved/open/new issues
• Open change requests
• Upcoming milestones
• Current and projected costs (depending on audience)
• Prior meeting's action items
• New action items
• Administrative items (vacations, holidays, etc.)

Depending on the importance and visibility of the project, a steering committee--usually involving executives from both sponsor and project groups--may be established to monitor the project from a business point of view and make critical decisions. If nothing else, bringing this level of scrutiny to a project will motivate all parties toward heightened diligence. Instead of focusing merely on the requirements and project operations, steering committees also help to remind the project team of the "big picture": the business case for the project.

To ensure that project team members take fuller ownership of their tasks and deadlines, take the following steps:

• Involve resources in estimating tasks when they are assigned, rather than simply dictate that a task must be completed in a certain number of hours.
• Require resources to report their own task status. Or at least be sure their names are mentioned when the status of their tasks is reported.
• Resources should not report their task estimates-to-completion as a percentage, but rather as a remaining effort. It is all too tempting for a resource to claim that a task is 95% complete. Instead, it should be reported that a task is likely to take another four hours. Based on the original estimate and the actual effort to date, a percentage can be derived if desired.
• Action items should always have one and only one responsible owner and an ETA, and items should be reviewed at subsequent status meetings.

Microsoft Project

MS Project is the standard in the industry for electronic management of projects, complete with Gantt charts, Pertt charts, resource lists, costs, critical paths, etc. Because it is so widely used, it is also a great mechanism for project managers to share information with team members, management, and the project sponsors. If part of large organizations, project sponsors often need to provide MS Project plans (MPPs) to their Project Management Office (PMO). Treating each individual project as a black-box, PMOs are responsible for ensuring that interdependencies between projects and implementation schedules align. Using MS Project, PMOs can quickly consolidate sub-projects into a master project, thereby getting the big-picture view they need.

If you are new to MS Project, its power and flexibility can easily overwhelm. Here are a few tips that may save you from struggling:

• MS Project's database has many fields of information, only some of which are viewed at any time--the Gantt Chart, Resource Sheet, and Resource Graph are three of the most useful views.
• MS Project's basic equation is Work = Duration * Resources. Manually changing any one of them will cause MS Project to derive the other two.
• Under Tools/Options/Schedule, select a Default Task Type of Fixed Work. Fixed work tells MS Project to adjust dates and resources as necessary, but only you can change the amount of work a task requires. This setting is sensible for most development projects.
• Once you finally have settings, views, and summary tasks the way you like them, save the project as a template (MPT). That way, your next plan will have a head start.

If used properly and updated regularly, MS Project plans encapsulate all the key task and resource information related to a project. It should typically be distributed liberally and reviewed frequently with project team members, management, and the sponsorship team.

The Key? Flexibility!

Projects are often said to have taken on "a life of their own." Should that surprise? Requirements cannot and should not ever be cast in stone at the outset of a project. Otherwise, one runs the risk of delivering exactly what was required but is no longer required! Ergo, shelfware! Instead, projects must be malleable, quickly adapting to changes in the business environment. Such adaptation often means taking on new requirements, and therefore, costs and timelines often increase. Is that all bad? No, not if Expectations Set = Expectations Met.


Steve Collins is a Services Manager for LANSA Inc., a premier provider of e-business and integration software tools and cross-industry custom solutions for the iSeries community, and winner of IBM's Powered by AS/400e Grand Prize Award for e-business. Steve can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it.
or 416-620-4306.