Friday, May 29, 2009

Defining the Project’s Scope and Requirements

The Strategy and Planning for the IT Transformation effort must emanate from the definition of scope and the understanding of the requirements that will be targeted by the initiative. Many compromises must be made in the process, and these compromises become both cause and effect of the ultimate strategic direction.

The compromises deal with the interplay of these parameters for each requirement:

§ Quality: The solidity of the deliverable

§ Cost: The amount of money available for delivery

§ Schedule: The expected delivery timelines

§ Scope: The functionality that is being delivered

These variables are known as QCSS attributes, taken from the initials of each. The business requirements can only reasonably specify three of these factors. The fourth factor will be a result of the project’s dynamics. For example, if the business wants a project done within certain cost restraints, under a specific timeline, and with a specific scope, the quality of the project will be in question.

In this diagram, Functionality is represented by the surface area of the square. The Cost used to meet the Functionality is shown in light grey, and the Schedule (timeline) is in dark grey. Quality is the percentage of the Functionality surface that is being covered by the Cost and Schedule squares. The diagram shows that if the Functionality scope is increased (larger surface), you will either have to increase the Cost, the Schedule, or both to match the new requirements; if not, Quality will suffer.

This “law” applies to all projects and to any combination of attributes. Furthermore, imagine the QCSS variables as knobs on a control panel, each influencing the other[1]. The more money available for a given project, the more potential resources that can be committed; thereby enabling faster delivery and/or more extended functionality. With less funding, chances are the scope will need to be reduced if timelines are to be maintained.

Managing the project budget and the timelines is a straightforward project management function. Project Management disciplines to effectively do this have been developed and can be applied in a systemic way. But truth be said, the most complicated challenge during this stage is to properly manage the amount of requirements you are likely to receive from the business. Let’s face it, this is an IT Transformation project that, most likely, has been sold as the mother-of-all-solutions and that will, no doubt, have the business salivating like a kid in a candy store with all the potential for functions that they have for so many years been deprived of.

However, the fact is that the requirements values tend to follow Pareto’s 80-20 rule. That is, typically 20% of the requirements represent 80% of the solution value, and the other 80% the remaining 20%. Now please don’t go to the business and tell then you will cover 20% of their requirements. Not a good idea. First, the Pareto principle is just that—a principle; not a law. It might be that in your case 40% of your requirements represent 70% of the value. Secondly, that little extra business value that can be attained by covering a few additional requirements might mean the difference between having a highly competitive solution or an also-ran.

What you first need to do is identify the 20% to 40% of the requirements that everyone agrees are a must, and then proceed to carefully analyze and prioritize the remaining requirements in light of their diminishing returns. My own philosophy is to do as much as possible with the money and time allocated (in essence, establish first the cost and schedule surfaces) and then draw a line in terms of what requirements are to be met during that first phase. You can place the unfulfilled requirements in a subsequent phase that might or might not be funded on its merits. If you can do so without eliciting the wrath of the business team, then you have succeeded!

As you can see, managing the overall scope is an activity best handled by the project leader and not to be delegated to line project managers. It requires finesse and political skills in dealing with business customers.

A second dimension that is often left unexamined during the requirements phase is the need to assess the project complexity and define the strategy of how this complexity will be managed. By this, I mean the determination of the strategy balancing the target automation complexity versus the reliance on manual processes. This is the subject of my next blog.

Till then.

[1] Microsoft article “A short course in project management” in also has an excellent explanation of the QCSS concept