Archive for February 2008
A project management tragedy in five limericks
With many changes we had to cope
Deadlines near; no money, no hope.
There was no way to wrangle,
with the iron triangle
of budget, time and scope.
The project was in a mess.
The reason I could only guess
was the carefully constructed
schedule was busted,
thanks to a dodgy WBS.
When called to explain the delay
I told the sponsor to pray.
When he asked, “But, why?”
I said with a sigh,
“On the critical path the tasks lay.”
He said to me, “This can’t be true.
There must be something you can do.”
Shaking my head
in sorrow, I said,
“All that remains is review.”
And now, I’m not in his pay,
You see, I was fired that day.
So, I exhort you all,
to stay on the ball,
and don’t run your projects this way.
W(h)ither, Corporate IT?
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.
Obstacles to project communication
Communication is so important to project success that it has been referred to as the life blood of a project by more than one practitioner. A recent post by Jack Vinson talks about the importance of communication across project interfaces – interfaces being boundaries between different groups within an extended project team. He views interfaces as constraints that limit project success. On reflection, I realised that many project communication issues I’ve encountered have, in fact, occurred at interfaces. In this post I explore the notion of an interface as an obstacle to project communication.
To keep things concrete, I’ll frame the discussion and examples in the context of projects in a corporate IT environment. For these projects the most common interfaces are:
-
between organisations (customer-supplier, for example),
-
between departments within an organisation (marketing-IT, for example),
-
between teams within a department (testers-developers, for example) and
-
within distributed teams (part of the team is in Boston and the other in Sydney, as an extreme example).
In my experience, the main communication obstacles (across interfaces listed above) can be boiled down three broad ones. I list these below with some pointers to how they might be addressed:
-
Political: Whenever there are many groups involved, there’s the possibility of vested interests and power games getting in the way of dialogue. Such political obstacles usually originate in the upper ranks of an organisational hierarchy, a step or two above levels at which projects are planned and executed. Project managers therefore need to make special efforts to be aware of the key political players in the organisation. In traditional corporate environments these might be functional or senior-level managers who aren’t always obvious project stakeholders.Once the political players have been identified, the project manager should take steps to gain their confidence and buy-in on project goals. This should help eliminate political barriers to project communications. In my experience, it is best to settle political issues at the level where they originate – escalating political problems up the hierarchy (i.e. to the manager’s manager) generally doesn’t help, and may even be counterproductive. Always keep in mind that political issues need to be broached with tact and finesse; inept handling can be a CLM. You have been warned!
-
Cultural: I’ll first deal with organizational culture , which is essentially the totality of assumptions and values commonly held within an organization. Clearly, this can vary considerably between organizations – some may be more open than others, for example. Communication at the interface between two organisations with vastly differing cultures can be difficult. For example, one might expect some differences of opinion at a joint project planning session involving a very forward-looking, can-do supplier and a conservative, risk-averse customer. Another example: in one organisation it might be considered perfectly natural for a developer to air a dissenting opinion at a meeting whereas in another it might not. Project managers can ease such difficulties by understanding the divergences in attitudes between the parties involved, and then acting as intermediaries to facilitate communication.In geographically distributed (or virtual) teams, differences between regional cultures can come into play. These could manifest themselves in a variety of ways such as differences in fluency of language, or social attitudes and behaviours. Here again, the project leader, and the rest of the team for that matter, need to be aware of the differences and allow for them in project communications.
-
Linguistic: Here I use the term linguistic in the sense of specialised terminology used by different disciplines such as Accounting, IT, Marketing etc. Often when specialists from diverse areas get together to discuss project related matters, there’s a tendency for each side to make assumptions (often tacitly) regarding a common understanding of specialised jargon. This often leads to incomplete (at best) or incorrect (at worst) communication. An article I wrote some time ago provides suggestions on improving cross-disciplinary communication in projects. If done right, project communication can help align IT goals with those of the business.
A wise old project manager once told me that over ninety percent of project issues he’d encountered could be traced back to communication problems. I’m not sure I can vouch for that number from personal experience (I haven’t counted, to be honest), but I’d have to agree that he’s right in spirit, if not in number.
A shared world-view – which includes a common understanding of tools, terminology, culture, politics etc. – is what enables effective communication within a group. Project managers can facilitate a common understanding in their projects by analysing and addressing communication constraints at interfaces.
Eight to Late 