IT governance: a help or a hindrance for your projects? Facebook has become a source of pithy quotes. One is doing the round in friends’ status windows right now is: “Follow your heart, but take your brain along with you.” In relation to IT, another way to put it might be: “No action without control.” Embarking on projects and service delivery without proper governance leads to …
“Methodologies don’t deliver projects, project managers do,” says Kevin Beard, head of telecoms, media and technology at consultancy PIPC."
Uh. And there was me thinking that the techs deliver the project despite project managers not talking to the users and getting the spec wrong in the first place, thus making the entire process take ten times as long (and more expensive) by constantly changing the spec.
I don't think so.
A good PM needs some technical clue, of course, but defining the project requirements is a job for the user dept and the project's Technical Manager working together. The users provide the requirements and the TM the skills to design a system capable of delivering the requirements.
I think not. More like you have to sit down with them and ask them what they need done. Then you create something that does that and ask them whether that fits in what they do all day. Listen to critiques and amend as necessary. Reiterate until done. Write all that down and deliver with the program.
Then again, most documentation is still written as an afterthought, including documentation specifically aimed at other developers. It's all written in "I just wrote the program, I know what it does" fashion; nowhere is any of it aimed at explaining how the pieces fit together and how they're ment to be used. Use of in-code documentation systems actually worsens this for it raises the semblance of documentation (generated in five different formats, all devoid of actual content) and excuses that nothing usable exists. Then again, buzzwords are all about make-believe anyway. The getting you all-abuzz part, you see. But I digress.
Now I do wonder what part of that deserved a 'why?' link that incidentally didn't answer that question. Takers, anyone?
"...without proper governance leads to disaster..."
Actually we seemed to do just fine before "governance" was imposed upon us. That's because the companies we work for tended to trust the professionalism of the highly paid resources to do a proper job. Personally I have only found they are yet another obstacle to delivery.
I have to agree with you there Steve, of say forty PM's I have had the pleasure of working with maybe one or two will actually add any value. The rest are just a waste of resources.
A couple of quotes spring to mind ......
The floggings will continue until staff moral improves
When asked about 'Western Civilization' Gandhi is reputed to have said ' I think it is a good idea'. The same might be said of 'IT Governance' ?
It's a PM's job to co-ordinate/manage requirements (via whatever methodology is deemed best to suit the work), and translate between teams that speak entirely different languages (User, Engineer, Management, Executive, Technician etc)
- Executive finances the project
- Business areas provide requirements
- Experts design solution
- Technical teams deliver the solution
- Management communicate new processes to staff
- PM slides in and out between all required teams to make sure everything's working well together (reactively and proactively)
This isn't really an IT discussion. It's true for every type of project in every industry.
And the cliche? It's a team effort
*blech* but true....
Fristly, Charybdis, I quite agree, it is a <blech> team effort. In this ever-faster world, it is more and more critical now for senior responsible officers/stakeholders know as quickly as possible the state of programmes & projects under their area (& costing them money).
How many projects have people worked on when what's delivered does not meet the requirements of stakeholders, users or don't meet the benefits? I would say "most". Although users are often the day-to-day customers of a new system/produt/whatever, they are unfortunately often left in the dark about strategic direction changes, so users often come up with requirements to "fix" existing practices rather than be included as stakeholders of new practices.
Governance is required to cross-brace across this change hierarchy to ensure that projects remain on track (to meet expected business benefits), status & change is communicated as fast as possible up/cascaded down so those responsible (not just stakeholders but programme & project managers too) can take the necessary decisions and actions, and to do all this in as efficient, pragmatic, repeatable and as least onerous as possible a way. Without this, programmes suffer from Grapevine or Telephone (more PC than ******* Whispers) whereby the message drifts or is watered down each level of the hierarchy it traverses.
Just think of the levels in your organisation and think how quickly such information does and should go from top to bottom and bottom to top. You will find they are typically very different answers. Top-to-bottom is typically very quick (a mandate from on-high but often without any real direction or how-to, just make it so [or JFDI]). For bottom-to-top, well, I have known a week or a fortnight and maybe even a month to just go up 1 level. For both, it should be instantaneous: anyone should be able to get a snapshot at any point in time based on real information used by and in use by real people on the project (e.g. requirements, risks, issues, build, testing). All these need to be weighted & categorised (quickly done) after which it is a relatively simple job to summarise at any level of the hierarchy.
It is a team effort, it's just that the team needs to be so much bigger (vertically) nowadays.
The other benefit is making those responsible responsible. Think of the banks or, even more recently, the NotW/News International.
The posters above with negative comments towards Project Managers obviously haven't dealt with one that's worth their salt. If you've worked with a good PM this article will appear as gospel, if you've only worked with bad PM's then this article will appear to condone the red tape that causes projects to degenerate into failure or a nightmare of moving goal posts.
To massively oversimplify things, a successful project depends on a good team, a good PM, good management above the PM and a supportive / interested board. The team is probably the least important as a good PM can work a sub-standard team to produce satisfactory results.
You can't fix bad management, regardless of flavour, with some fancy new buzzwords. Good management, doesn't need them. Buzzwords is all of what this article offers. Thus it appears apparent that the article has a rather orthogonal relationship to improving management.
There's another area of governance, that can be quite thin, that prevents business managers and suppliers proliferating the deployment of non-strategic point solutions to nail their short-term targets. The individual business cases for these projects can look compelling but unless there is real governance around the enterprise architecture and the IT strategy, the costs of administering and integrating this mish-mash can escalate out of control. In my experience, code monkeys are only too pleased to immerse themselves in these 'highly focussed' projects as a means of demonstrating their prowess and, if the end result nails someone's promotion or sales target, they can develop an unstoppable momentum. The key to keeping the enterprise architecture and the IT strategy firmly on track is buy-in at board level and having senior IT management with a clearly defined architecture linked to the vision for the business. Fail to do this and I can show you examples of 'quick wins' that have cost organisations £millions in the longer term.
David Gale
CEO
SITFO.org
... rewrite the above more resembling normal people-ese, please?
If your code monkeys are focusing on showing off on tangents to the core business, then I submit that is an equivalent symptom to managers forming kingdoms and having turf wars. Needless to say, but I will tell you anyhow, since you're CEO the buck stops with you.
Next question: Mister CEO sir, what will you do?
I've played b*ll**it bingo .... I think I know this one... translation follows -
I am the CEO of an organisation which is going down the tubes. Many of the problems can be attributed to our inability to retain either good technical, or sales staff.
Hopefully the company can be saved by being sufficiently insulting to the technical and sales staff, and an incomprehensible architecture diagram.
This post has been deleted by its author
@DG. Great if boards were not as thick as planks. So far, I know of none who had a clue or seemed to want one. What I do see are are clerks in suits (managers is how they style themselves) who like to create not IT kingdoms, but fiefdoms of paper driven procedural droids, creating processes to stop things happening, so they can be involved in "managing" them. Outsourcing amplifies this degeneration of the organisation into mutually hostile camps.
eg; Since IT governance, to use the current term of abuse, consists of adversarial relationships, you have client change control, PMs, designers, spec writers and a sprinkling of managers. On the Finance side, more managers and a PM/co-ordinator or two. Repeat for sales. Finally, the IT team will have the same as the customer/client, plus hopefully, a coder or two. Missing are the actual business users. Standard process strait jackets will be used, including using off the shelf stuff which fits the PHB decreed product lists, whether or not they work. Success is judged by how well the paper is pushed, processes comply with the process droids wet dreams and ensuring no-one can be blamed.
No wonder goal posts become sprinters, IT staff become paper pushers and whatever gets delivered is, at best, a disappointment. The mess is controlled badly by invoking some set of guidelines (ITIL, say) which is implemented as a set of draconian rulez to keep the suited clerks sense of power fueled. The process is well described in "Skunk Works" by Ben Rich describing the horde of process droids hindering the development of the stealth fighter.
In the bad old days (TM) the business owner would approach the IT department, describe their issues, discuss it with them, often with involvement of knowledgeable users and decide on possible solutions. IT would get costings. Client dept would do their budget or apply for funding and get it. Once funding approved the project would be built and running, with fixes and upgrades as required in test and acceptance phases. Old system would be switched off when client happy, which happened quickly because they owned the system and helped design it. The IT manager would not co-operate in allowing a proliferation of OS and applications, unless customer had a very good reason. Problems were solved by people talking to who-ever was responsible and discussing how to fix problem, not how to develop a process to fix problem.
AC because this is situation too familiar in 3 TLA firms I worked for.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
