Eight to Late

Many project management books contain a section or two on managing stakeholder expectations. The emphasis in most of these tomes tends to be on the bureaucratic aspects of the process - developing stakeholder management plans or getting the project scope statement signed off, for example. Although documents and signatures may be useful in proving that you’ve performed your duties with due diligence  (aka CYA),  they don’t guarantee stakeholder satisfaction. Despite reams of documentation, a good number of projects are deemed failures because of a mismatch between stakeholder expectations and completed deliverables.  I’d go so far as to say that chronic project failure is one of the main reasons why many corporate IT departments get a bad rap.

The root of the problem, in my opinion, is that documented requirements very often do not reflect what a client really wants. It is impossible to get a comprehensive view of client requirements in a limited number of analysis sessions. This difficulty is particularly acute when one tries to document all requirements in one go, as is the case when a waterfall development methodology (also known as Big Design Up Front or BDUF)  is used. It is well known that Iterative / Incremental methodologies are better because they ensure that requirements are reviewed and revised several times in the development cycle. Incidentally,  this article by Joe Marasco  has an excellent, visual explanation of why iterative development is superior to BDUF.  Despite this being common knowledge, many corporate IT departments remain stuck under the waterfall. Why this is so is a topic for another post - I’ll just take it as a given here. However, consequent stakeholder dissatisfaction is one of the major reasons why these departments have low credibility within the organisations they serve.

So what can be done about this?

The two-word answer: better communication.

The one-sentence answer: adapt flexible stakeholder management practices from the Iterative/Incremental world and integrate them into your BDUF approach.

The longer answer:

Iterative/Incremental approaches mandate regular meetings between stakeholders and project team members. Consequently these methodologies have stakeholder management built in, as opposed to BDUF approaches which don’t require regular interactions.  So when using BDUF methodologies one has to work doubly hard at communicating with stakeholders. When doing so, it is a good idea to adapt practices from Iterative/Incremental approaches and integrate them into your development methodology.  In particular, the following points are worth considering:

• Frequent feedback: You don’t need to schedule formal meetings to give people status updates or feedback. Wander over to their office to have a chat and give them an update. If you make a habit of this, you may even find that formal meetings are required less often.
• Frequent delivery (or demos): Although BDUF methods appear to preclude frequent delivery (as opposed to Iterative techniques, which mandate frequent releases), it is often possible to show users work in progress. Schedule informal demos of work in progress where a developer shows end users the current state of the product. By doing so, you may get feedback early enough to do something about it. It’s no good having users complain about the user interface at the final demo.
• Flexible attitude: Yes, I know, your requirements are frozen (the users have signed off on them, after all). However, if you can accommodate changes, it is best that you do (via whatever change control process you have).  A blanket, “Next phase” response to all change requests will only annoy your clients. A flexible, can-do attitude will go a long way in getting users ”on your side”. Once they see that you do your best to help them, they’ll (usually) reciprocate by not asking you for the moon. Further, on the rare occasions that you turn them down, they’ll (generally) understand that you’re doing so for good reasons. 
• Present alternatives when saying no: This is important. If you do have to say, “No” to a user request, try to present a viable workaround or alternative. Often, a well thought out alternative may be more than enough to satisfy the user. Besides, it also gives the user a sense that you are working with them to solve their problems, and not off on your own trip building something that is divorced from their needs.

That’s it. I know, when you look at the list the points seem pretty obvious. However, they are hard to apply in practice - not just because of recalcitrant users, but also due to the numerous constraints on project teams operating in BDUF environments. In practice you’ll also find that these techniques work better on some projects than others - mainly because of differences in user attitudes.

Everyone has great (or should I say, inflated)  expectations from things to come. This invariably leads to disappointment in the end. A good part of managing users is to  make their expectations more realistic rather than lowering them. The best way to do this is by involving users as much as possible in the development process. This essentially is what Incremental/Iterative and Agile techniques advocate.  BDUF practitioners - which include many corporate IT development teams -  should take a leaf from their book.

Mother Goose for Project Managers - version 0.001:

Little Jack Horner
Little Jack Horner sat in the corner,
watching his budget run dry.
Said he to the sponsor, “The project’s a goner.
and I reckon, so am I.”

Hickory-dickory dock
Hickory-dickory dock
The PM’s in shock.
The project’s aground;
the clock’s run down.
Hickory-dickory dock

Jack be nimble
Jack be nimble,
Jack be quick.
Dodge responsibility,
for it tends to stick.

Hey diddle diddle
Hey diddle diddle, the schedule’s a fiddle.
The deadline’s near; it’s too soon.
The sponsor won’t smile when he sees what’s been done,
especially after being promised the moon.

Hush-a-bye PM
Hush-a-bye PM, on a timeline.
Better wake up now, things aren’t so fine.
The scope is a-creeping, are you on the ball?
No change management will be your downfall.

Schedule, Schedule
Schedule, schedule on the wall,
the PM’s going to take the fall.
’cause everyone can plainly see,
his timeline’s but a fantasy.

The PM can’t sleep
The PM can’t sleep, he’s counting sheep.
The project is what’s troubling him.
Changes galore. Tell you what’s more -
there’s no money left to fund ‘em.

Blah blah PM
Blah blah PM, spouting bull.
I can’t take anymore, my plate’s full.
The workload here is driving me insane.
So I’m leaving for a gig with the mob down the lane.

Consultants are engaged for a variety of reasons ranging from strategic (e,g. help develop corporate IT strategy) to tactical (e.g. augment internal resources). They are so ubiquitous that at any given time  an organisation is likely to  have a bunch of consultants floating around in one department or another. Given the often outrageous rates billed by high-end consultants, it is important that organisations get maximum bang for their consulting buck.  When I worked as a consultant I often came across situations where my services could have been better utilised. On the other hand,  as a corporate employee, I’ve seen consultants hanging around doing very little. So I’m convinced that many organisations often underuse or misuse the consulting time they’ve paid top dollar for. This doesn’t have to be so.  It’s easy to ensure that you get the best value from the consultants you engage. Here’s how:

• Know why you’re hiring them: One would think this should be obvious, but it often isn’t. Ask yourself why you’re engaging consultants and what (specifically) you want from them. The best way to be specific is to list the deliverables you expect from them. This gives you a checklist you can tick off as they progress through the engagement.
• Be ready for them when they come in: Over the last several years I’ve been surprised at the number of consultants I’ve seen hanging around the coffee machine or twiddling their thumbs (whilst racking up huge charges) , all because  the client wasn’t prepared properly for them. This is like keeping a taxi waiting - the meter’s ticking but you’re no closer to your destination - a waste any way you look at it.  Be prepared for your consultants: ask them what they’ll need before they come in, and be ready with it. You want them working on productive stuff as soon as they arrive.
• Listen to what they have to say: You’ve hired your consultants for a reason - presumably because they have something useful to offer you (knowledge, skills or whatever). It therefore behooves you to listen to them when they offer opinions (which may well be contrary to yours).
• …but ask for explanations: Listen, but don’t be uncritical - you want the what, but you also need the why. Ask for explanations if you aren’t convinced. Ideally you want hire them only once for a particular job. The next time around you should know how to do it yourself.
• Ensure knowledge transfer: This is really implied in the previous point. However, it is so important that I thought it worth mentioning again. You want to make sure that they’ve transferred all relevant skills to internal staff.
• Document, document, document: This is a frequently overlooked aspect of most consulting engagements. Sure, consultants leave you with a final report. But that report, in my experience, is often less than useful. What you want are working, nuts-and-bolts documents like standard operating procedures. Be sure that your consultant leaves you with useful documentation. Have your people check the documentation before the consultant takes off with your cash.

Few present-day organisations can afford to maintain all the skills they need in-house, so most have to hire consultants every now and then. Your organisation is probably no exception. The aforementioned suggestions may help maximise the return  from your consulting dollar.