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.

History repeats itself;  first as tragedy, then as farce - Karl Marx.

Although Mr. Marx didn’t say anything about repetitions beyond the second, one can safely assume he would have considered them beyond farcical. Yet, in the world of corporate IT, we’re continually faced with the following repeat offender:  the solution in search of a problem (or SSP).  I should define the term before I go on - a SSP is a project that has been sanctioned without any regard to  the actual value or utility of the deliverables. This post is aimed at assisting project managers in identifying a SSP, so that they can take appropriate action when confronted with one. This basically amounts to of the following: sidestep it (i.e. duck it somehow), step down (i.e. resign) or suffer (i.e. accept the responsibility of managing the project and, well, suffer).

So, here we go then, seven deadly signs of SSPs:

1. No one knows what the project is about. Everyone talks about it, but no one seems to know why it is being done.
2. It’s all about technology or standards (SOA anyone?), not the business. The justifications on offer for the project are seasoned with phrases like “best practice” or “state of the art technology”; terms that  have more to do with technology than business need.
3. There’s a committee responsible for implementation (often with a global reach). You’ve got to love global committees with their 10,000 metre view of ground level realities. Most recommendations that emerge from these are either so general as to be unusable,  or worse -  patently incorrect. 
4. Since no one knows what it’s about, the project is more about the means than the end. Put another way, project management processes or process improvement methodologies in their full bureaucratic glory will reign supreme. Be sure that you’ve filled in all the right forms and have all the right signatures, else all hell will break loose.  
5. No one is aware of a successful implementation: The global committee has little to show for their three years of the project, barring the pilot they did two years and nine months ago,  involving 1.5  users. 
6. The project will replace a perfectly good existing solution: You have a good system in place? Don’t worry, the SSP will replace your tried and tested solution with  one that will give your staff many  hours of debugging fun, and the gray hairs to prove it. 
7. And finally: these projects often originate in the upper reaches of the corporate hierarchy, where the connection with  ground level reality is somewhat tenuous. Corporate mandated projects have a fair chance of being SSPs.

So, it isn’t hard to spot an SSP. What do you do if confronted with one? Well, that’s up to you. As mentioned earlier, you have three options: sidestep, step down or suffer. The choice is yours.

A manager’s response to A corporate IT tragedy in five limericks:

I see you have taken offence.
But axing your job made good sense.
You had to go
to save us some dough,
and that’s why you are in past tense.

It broke our hearts to do it,
but it’s because of the market.
Our bottom line
has to climb
a long way to make us a profit.

Let me say this just between us:
For savings, on me was the onus.
And it’s better to see
you gone, than me.
It may even earn me a bonus.

I know you will soon secure
another big fat sinecure.
Where you’ll do no work,
and continue to shirk,
while gaining promotions galore.

And so I bid you adieu;
and many good wishes to you.
See, writing bad verse
may feel good at first,
but later you may just get sued.

They tell me my job’s on the line
I think it’s for real this time.
The bosses, they say,
“Your job’s going away,
it’s heading for sunnier climes.”

This time it’s gone really far.
I reckon they’ve been reading Carr.
Who tells us that IT,
is just a utility.
Strategic it isn’t, for sure.

Consequences of centralization -
servers in another nation.
Miles away from here.
Too far, I fear;
QoS goes to hell - “Oh damnation!”

Every little bit and byte
traverses a long and thin pipe.
All the way to our users
who’ve become snoozers,
waiting for docs from last night.

I know the circle will turn.
But not before users get burned,
by rotten support.
They’ll see it’s a rort,
then bring the whole darn thing back home.

If you enjoyed this piece, you may like to read my project management tragedy in five limericks. Feedback is welcomed via your comments.

Nicholas Carr’s latest book, The Big Switch: Rewiring the World from Edison to Google, predicts that corporate information technology (IT) shops will eventually be replaced by computing utility companies akin to the power and water utilities we’re all familiar with.  Carr’s writing is always interesting and thought provoking,  so I’ve duly placed an order for his book (which I’ll review in a later post). The central thesis of the book, the switch to utility computing,  appears to have evolved from the ideas he articulated in a piece entitled, IT Doesn’t Matter, which was published in the May 2003 issue of Harvard Business Review (HBR).  I read the article not long after it first appeared,  and filed it away as something I’d want to read again later.  With the book just out,   now is perhaps a good time to take that second look,  and discuss some of the consequences for those who work in corporate IT.

The basic thesis of IT Doesn’t Matter is:

There is no strategic advantage to be gained from maintaining in-house IT departments because IT is fast being commoditised.  As a consequence of easy access to all, it no longer confers distinct advantages on any.

In the article, Carr draws a parallel between the present-day computing industry and power utilities at the turn of the last century. He points out it was common for industries in the late 1800s to have their own in-house power generation plants. At the time electricity was a scarce resource that offered manufacturers distinct advantages over traditional power sources such as water mills. Hence those who could built their own, and thus gained a strategic edge over those who didn’t. Power utilities changed everything by bringing cheap, reliable electricity to the masses.   Once this happened, any industry  - big or small, rich or not so rich - could access electric power inexpensively without having to go through the hassle of generating it themselves.  In-house power plants went the way of the pterodactyl and the rest, as they say, is history.  

Carr argues that the IT industry is being rapidly commoditized in much the same way as the power, railroad and water utilities were in the late 1800s. That this is happening today  is undeniable, and is apparent   from the increasing number of vendors providing fee-based hardware and software services.

As might be expected, the article generated a lot of discussion. In June 2003 HBR published a “debate” featuring a selection of letters along with Carr’s reply. Additionally Carr maintains a compilation of annotated links to article responses on his Web site.   I found it interesting that many corporate IT professionals tend to agree with Carr (in substance, if not detail)  but big  vendors and consultants, who potentially stand to gain from the change,  don’t.

What do I think?

Well, it is clear that Operational IT - the “lights on” business of keeping servers and networks humming along - is already halfway (or more!)  there. Countless providers offer  dedicated servers at very affordable rates, with the added attraction of not having to deal with any of the maintenance issues in-house. Many small businesses do just this, and larger ones consolidate several small IT units into  internal data centres.

For IT Development, however, the case isn’t quite as clear. Granted,  shrink wrapped products such as MS Office face competition from open source products and web-based software services, and at the other end of the spectrum, large enterpricey apps such as <insert any random ERP or CRM system here> can, and are, being provided as services too. In the middle, though,  lie countless applications that address important business needs,  but are too small and specialised to be of interest to potential providers of computing services.  What about these? Well,  present-day software such as spreadsheets and desktop databases  are loaded with features that enable technically savvy business users to build their own specialised applications.  Many end-users do so (thereby causing much angst to those who run corporate IT!).  Additional features and improvements in the useability of such software will only accelerate this trend, thereby obviating the need for dedicated IT resources to build and maintain these applications.   

What remains then? Clearly, not much in the way of technical jobs. Yet, corporations of the future will need people to manage vendor relationships, run projects and provide unbiased technical advice. These folks would need to have:

• A good understanding of the business.
• Good communication skills.
• The ability to manage complex vendor relationships.
• The ability to manage complex projects involving external parties.
• A broad (but not necessarily deep) technical knowledge.

The future corporate workplace envisioned by Carr will be radically different from the one IT professionals are familiar with. However, it will have a place for those technical people who focus on business issues rather than technology.