|By Adrian Bridgwater||
|September 20, 2013 05:00 PM EDT||
Project management analysis is a dangerous topic. It is very easy to sit back and talk about flawed project direction and targets as we point to the number of failed IT programs that seem to crop up repeatedly.
If we are honest about it, do any of us even notice survey statistics claiming that 30% or 50% (or whatever percentage) of IT projects fail today? We have become immune to this scaremongering and simply regard it as par for the course. This makes the situation worse as we enter a vicious circle of IT project projections where we expect a certain amount to fail anyway.
Reasons to Be Worried About Project Management
As it stands today, we can say that IT projects often fail for a number of key reasons:
- The technical staff did not have the specialized project management skills needed to carry through the project.
- The project management "business function" was not fit for the job and could not therefore support the technical crew.
- So-called "project skew" was rife from the start and the development program never really got past the blueprinting stage.
- The customer put forward so many irrational demands in terms of functionality requests that the "requirements" process was inherently flawed and doomed from the start.
- The project was not properly cost analyzed and so simply ran out of funds.
- Key members of the project left during the workflow and failed to annotate their work sufficiently such that others could pick up where they left off.
- An act of god or natural disaster befell the project.
That last one was a joke just to see if you were paying attention okay? But in a way it's not a joke. All manner of excuses are tendered for why projects fail and if you happen to see "tsunami" listed as the reason a project went under, you know someone is pulling their hair out so badly that they've just written something crazy down.
No Excuses Left, Surely?
The question arises, hasn't project management run out of excuses yet?
If we know how often these (above) and other similar excuses are being used, then shouldn't hard and fast project management considerations be "baked in" from the start of every single software application development and/or database-centric project that exists?
Would that it were so. It comes down - predictably, of course - to money.
Like many of the large vendors today, HP has a fairly rich set of project management offerings to sell. The company positions the discipline one mezzanine floor (or tier if you prefer) higher in the sense that it talks about projects and software portfolios in the same sentence. The "portfolio" part of the project proposition is not only alliteratively easy to remember, it also means that we're not treating any single chunk of technology as a silo - and silos as we know lead to bad integration, to inefficiency, to bad IT all round.
Tools like HP Project Portfolio Management Solution (HP PPM) provide users with a dashboard view into a portfolio, incoming IT demand, in-flight projects and other programs across the organization. But this doesn't come free, so it will come back to money again.
If the business can identify the fact that investment in PPM solutions enables smart portfolio investment decisions that will eventually pay for themselves, then that's great. If it's a smaller organization or development shop that can't afford that kind of expenditure, well then they should be small enough to get on with one another properly in the first place and not need project management tools to that kind of formalized level right? Well no - but you get the point, there are no more excuses, so get your project in line.