Project Management Book

...chapter 2 continued

Let us turn to the other end of the spectrum - making small enhancements to existing IT systems. At the extremes there are two ways of dealing with small enhancements. At one extreme is the ad hoc approach: each time someone raises a request to enhance, it goes to IT, a programmer dives into the code, makes the change and it goes live whenever it's ready. The obvious benefit is that it is quick - assuming you have enough IT guys waiting around. Also, it doesn't require much management.

The alternative is to bundle, say, 20 enhancements together into a project - again let's call it a release. During a year perhaps there will be four such releases on February 1st, May 1st, August 1st and November 1st. The rule is that the live production system doesn't get changed between releases except where there is an overriding need. What might be the benefits of this approach? It's certainly predictable: the users know when each release is coming and can plan around these release dates in terms of resources for testing, procedural changes and so forth.

IT will probably do more thorough testing. There's an old adage amongst programmers: "It's only a one line change, it doesn't need testing". Into production it goes and crash, the live system comes tumbling down. You can't spend a week doing safety check, regression testing of a one line change. But if it's part of a quarterly release it's much more likely that there will be proper regression testing.

Economies of scale: it can take a programmer days to understand a complicated program before he changes it. If a number of changes are made at the same time the understanding overhead is borne only once. Doing those changes ad hoc would have meant re-understanding the program each time.

The sheer act of promoting updates to the live environment costs money - do it every quarter not every other day!

"If it works don't fix it." Every time a change is made to the live system there's a chance of a mistake. If the system is working acceptably leave it alone.

One of the biggest benefits of the release approach to enhancements is that some enhancements simply don't get done. Doesn't sound like a benefit? Consider this: how often does a user shout loudly, "I want this changed, it's really urgent and important!". The change is made but a week later the user can't even remember why he wanted it. With a release approach there is more scrutiny of each potential enhancement and ones that aren't worth doing are weeded out.

Bottom line, it's cheaper to do enhancements as releases: you're trading the speed of ad hoc against the efficiency of releases.

Again, what is right for you will depend upon your environment. In a rapidly moving web-based retail environment a daily update of the program code that drives the website might be worth the cost and the risk, but even here grouping changes into less frequent, planned updates could well be beneficial. By contrast, for the system that administers your company's pension scheme perhaps an annual release is best with changes between releases only if they are absolutely essential.

How does this release approach to enhancements work, what is the process? Sometimes it works like this:

• User sends enhancement request to IT
• User never hears anything about it ever again

We should be able to do better than that. Most IT groups have a service level agreement (SLA) with their users. One item in the SLA might be: within 3 working days of receiving a request to enhance we'll get back to you with a ballpark estimate. This ballpark estimate enables the user to determine whether the enhancement would be worth doing given the cost. If so it becomes a candidate for a future release. But who decides which release, if any, it gets in to? All too often in the past IT decided and the perception was that IT didn't give the business what the business asked for and needed.

There is another way.

The IT systems that run the business are company assets. Assets need owners. Suppose the Marketing Director becomes System Owner for the company's order processing system. What responsibilities would he have?

• Account to the Board each year for the running cost of the system - this tends to stimulate efforts to reduce running costs
• Be accountable for the system's legal compliance - if the system puts the company in breach of the law somebody has to stand up in court
• Be accountable for every penny spent enhancing the asset - decide which enhancements get done and which don't get done

In a small company the System Owner can personally decide which enhancements get done but in a large company he will be too senior to do that so will delegate to his "Owner's Representative" - a less senior business person. The Owner's Representative prioritises the enhancement requests and, for example, recommends if only one could be done which one it would be. It becomes the Owner's Representative's job to recommend which enhancements get done in which release. Of course, genuinely urgent enhancements and fixes will short circuit the process and get done now as an exception to the "no changes between releases" rule.

Where the process works best the Owner's Representative meets informally with his IT counterpart every month or so to discuss what's coming down the track and what the priorities are. IT will suggest which enhancements it makes sense to do together for technical and cost reasons. Their discussion will include consideration of the IT resource plan (see Fig 3).

Figure 3: IT Resource Plan

Imagine you are the Owner's Representative for the Invoicing system. It's March and you're contemplating the contents of Release 3 which starts in June and delivers in December. Currently 2-3 IT people are planned to work on Release 3. But you, the Owner's Representative, add up the estimates for everything you'd like in Release 3 and realise it would need 12 IT people to deliver everything you'd like as opposed to the 2-3 that are currently assigned. Who has the problem? You the Owner's Representative or IT? You do. It's your job to balance the contents of the release and the IT resources. It doesn't balance so what do you do? You'd consult with those who raised the enhancement requests and say "we can't afford to do all of these, which ones can we live without?" Note we can't afford to do all of them. Not "IT won't do them all for us."

By mid April you've pruned it, say, to 8 person's worth or work, but you're still 5 short. What might you try now?

You might approach the Owner's Representatives of Billing and Purchasing to see if they'll let you have some of the IT staff provisionally assigned to their projects. And what will they say? "We need more IT resources too..." Worth a try.

At some point you believe you have a strong case for more IT bodies to be assigned to Release 3 so you approach your System Owner.

The System Owners meet once a month to decide, inter alia, whether they want to re-slice the IT cake. Maybe your Owner wins you the 5 bodies you need. But if he doesn't, you have to cut the release content back to what can be delivered by those 3 IT guys.

This is a business led process by which the business decides how they want to use their limited IT budget.

The business now have a nice plan showing the content of each release and the IT resources planned for each release. But what else should the business have a plan for? Can the IT people do these projects on their own? They most certainly cannot. Business users will need to define detailed requirements, be involved in and agree designs, do some testing, be trained in the new system features, and so on. Indeed, the user cost could be as great as or even greater than the IT costs.

But have you ever seen a plan which shows the business how much of their resource will be required for all these "IT" projects? Such a user resource plan often exists for a single large project, but a plan that adds up all the user resources for all projects and thus tells business managers how much of their resource will be needed for project work month by month is a rare thing indeed. And if nobody tells the Marketing Director that, say, 20 of his 100 people will be needed for project work what will he tend to assume in his planning? Zero. So every time a project manager needs a body from Marketing it's going to be an uphill battle.

There is a reason why project resources are not factored in to business managers' headcounts. Go back twenty or thirty years: there were many more people employed to administer the business and fewer projects, so the percentage of a business manager's resources assigned to project work was relatively small and didn't need to be planned specifically. Today automation means far fewer people administering the business and the pace of change means there are many more projects so the percentage of a business manager's resources assigned to project work is much greater and must be factored into business managers' headcounts.

It may even be appropriate to give one of the Directors an additional responsibility: Director of Change and Project Resource Planning. At its simplest this means asking project managers how much resource will be needed for their projects month by month (and if they don't know make them guess - anything is better than a zero estimate by default) and then add up all these resource requirements to show how many people (or FTEs - Full Time Equivalents) each business area will need to set aside for project work.

The first time the totals of business resources for projects (see Fig 4) is presented to the Board their reaction may well be "we can't free up that many from running the day to day business!" which can then lead to a constructive discussion about the organisation's capacity to do projects.

Figure 4: Business Resources for IT projects

If the Marketing Director has 100 people in his empire but the analysis shows that 20 will at any time be assigned to projects (many more than in the chart above where it's only between 1 and 6), he knows he really only has 80 people to do whatever Marketing does. He should have to account to his boss only for how he has used 80 people. Who accounts for how the other 20 are used? Those sponsoring the projects that use those 20. And indeed the Marketing Director's boss should make it clear to the Marketing Director that those 20 FTEs must be working on projects.

One could even consider having everyone in the company do time recording each week. If someone had spent all last week doing their "proper job" there could be a default time record, but if that person spent 10 hours user testing project X they must record those 10 hours against the project X time code. Then perhaps for the first time the company will begin to understand the true cost of projects as opposed to the IT tip of the project cost iceberg.

How does all this help us as project managers? Fairly obviously if you ask Marketing for a resource you're more likely to get a positive response if it's in the Marketing resource plan. It doesn't guarantee you'll get the resource or the right resource but it makes it more likely.

This is all part of the shift in company culture from process-based to a project-based or at least from a project-inhibiting culture to a project-enabling culture.



...next

Privacy Policy and Cookies