Project Design—Success is a Process

It seems unusual to hear about a successful technology project. An average general contractor can get a house built in a matter of months and achieve the same thing repeatedly. Are technology projects just that much more complicated? A review of success factors and the comments of project participants shows frightening and avoidable conditions. Too frequently basic project realities like understanding of requirements, structured project planning and budgeting, and consistent management are either overlooked or ignored.

Technology projects in a large enterprise can be complicated, but success and failure are process outcomes that can be anticipated more often than not.

The Standish Group conducts and publishes extensive research about project success (the CHAOS) report, and its work consistently reveals that information technology projects present an unacceptably high risk of failure. They categorize project outcomes the following way:

Resolution Type	Status	Description
1	Success	The project is completed on-time and on-budget, with all features and functions as initially specified.
2	Challenged	The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.
3	Impaired	The project is canceled at some point during the development cycle.

The statistical distribution of projects among these categories varies slightly year-by-year, but the sad, avoidable reality is that significantly less than half of all information technology projects can be called a success according to these criteria. With the number of successful outcomes adjusted to account for trivial efforts that would have succeeded even if no one had shown up for work, the probability of success looks unacceptably low.

Altis Can Help You Be Successful

Altis can help mitigate project risk by supporting project design according to these basics:

Requirements: Passion does not define a requirement.	The most common wrong-foot beginning to any project is to treat needs and desires as equivalent. Contrary to occasional individual perception, passion about a topic does not necessarily mean that it is relevant. Feeling strongly about a feature or function doesn't make it a necessity. Conversations about requirements can be challenging, but sorting out this key distinction diplomatically and early is essential.
Scope: Begin the journey with a destination.	The boundaries of the project must be clear. In fact, clarity about a project is one of the fundamental conditions necessary for communication. If the deliverable must be green, we all need to know that. Attempting to creep the scope will cause adjustments to budget and schedule. If a proper change management process is in place, this becomes an exercise in management and accountability. Without change management, the adjustments will simply force the project into a challenged state (resolution # 2). A risk management plan should be associated with the scope.
Budget: Expecting more for less is as effective as buying lottery tickets hoping for a steady income.	Budget is the quantitative reality of effort over time. The participation of people costs money. The equipment the people need costs money. The technical details associated with successful production cost money. A detailed build-up of the project budget clearly describes the resources required to be successful. If you want to save money, do less. Expecting to get more for less—the Lotto model—generally works the same way that buying lottery tickets provides a steady income.
Schedule: We don't try roasting a 15lb. turkey for one hour at 1,750 degrees at home, so why try it at work?	If a 15 lb. turkey will roast in about five hours at 350 degrees, we should be able get it done in one hour at 1,750 degrees, right? If it isn't right, why do we come to work and try to get away with thinking like this? (Vegetarian diets don't seem to offer such good analogies.) Building a project schedule takes into account how much of the necessary work people can do over time. Various project dependencies preclude accelerating beyond a certain rate of progress, so good schedules cook the turkey according to the known rules of success. The plan and the schedule are closely related deliverables and are usually representations of the same data stored in a project management program such as Microsoft Project.
Reporting: Good news won't last. Bad news gets worse.	Well run projects generally use some sort of frequent dashboard reporting to keep everyone informed. This means that the only things documented for the purposes of status are the relevant details. For example, the percentage of the work that is complete should correlate accurately to the percentage of the budget expended. Deviations in this relationship are red flags. On-time and on-budget should also correlate. A 10% negative deviation in the schedule or budget is nearly unrecoverable, so vigilance at every turn in essential. Remember, in running a project, good news won't last; bad news gets worse.

Situations vary, and organizations present their own unique challenges, but a well scoped, well planned, and well run project is much more likely to be successful. It will be enjoyable work, too.