Large IT projects are notoriously doomed to failure. So what are some of the warning signs?
7. Your CTO makes technology decisions by reading Gartner reports or what his CTO buddies think is cool this month.
6. You pay an outsource company by-the-hour to do your development work, but they're not bound to a deadline. Or a budget.
5. The budget for your project is measured in "millions", and timescale in "years".
4. You have so many business analysts, you just refer to them as "BA's"
3. The majority of staff on the project don't work for your company or organisation.
2. You have, proportionally, more consultants or business analysts working on the project than developers.
1. Someone in the project has the title "Lead Business Analyst".
Comments
Wow, I think someone is a little critical of consultants. Let's go through them shall we?:
7. Well, as long as you can critically look at the technology and determine if it does work within your organisation then there is nothing wrong with this. IT people are encouraged to share their approaches and technologies and that leads to better projects as presumably someone else has done. A 'not-built-here' mentality is not going to help.
6. This is not because of the consultants, it's because you didn't set a deadline. The same would happen if you did it in-house. Why do you think the SOE project has been going on for so long Peter? No deadlines!
5. There are many projects of this size and scale that have become successes. Have they gone over budget? Usually. But this is because it's hard to estimate the size of normal project let alone one that spans multiple years. Will it be doomed to failure? No. With this attitude things like the Access card, e-tax and other large projects would never be funded.
4. Nothing wrong with this as long as your project requires this many BA's. This is more of an over skilling issue. The same would apply if we hired too many Release managers (arguably worse, since they'd ban together and never allow anything to be released unless it had approval from each of them...in triplicate)
3. Rob Thomsett talks about this alot, and it's a whole new way of managing to be sure. It requires a lot of management oversight and well laid out plans. Why do you think that the IEEE has spent a lot of time creating standards for this situation. It's better to hire someone with existing skills for a short time then train someone in your organisation who will probably never use that again
2. See point 4. And some of those consultants are probably also developers. And if you're really running your project with too much management overhead then you obviously have done no planning and resource allocation at all
1. So what you want is a group of BA's all working on their own little thing with no one person in charge or responsible? That's what a lead BA does. They ensure the other BA's (and the project) are actually going working together.
It seems to me that someone is stuck in the public service attitude of 'not-built-here' attitude and an aversion to the outside. Your misguided attack on BA's (not surprising since you live with one, and I'm sure this is a dig at her if not anything else) is wrong. It's bad planning that is cause of all projects from failing. And proper planning would prevent all the things above from happening. That these points actually occur and that those projects fail shows that planning is important lest you waste all your money on BAs.
Good points Joel, I know the majority of the post is a dig at me to get me riled up but it definitely highlights Pete's classic "Public Service Attitude". What I mean is the typical "I work only what is required and I perform work outlined in my role description. Anything that was paid for (an IT project that I wasn't involved in, or someone I know was involved in) must be a waste of money. Now I'm not saying that all public servants have this attitude, but it is a common one that you face, especially in IT.
Peter also doesn't make the distinction between consultants and contractors (he uses the word consultant but appears to be referring to contractors). Most permanent staff don't recognize the difference:
- Contractors: are employed by the organisation for a defined period to perform a specific role. They work hard, work longer hours and are far more accountable for their work than permanent staff.
- Consultants: are generally employed by an third party external organisation for a shorter period of time (generally less than 12 months) to provide an external perspective, specialist advice or provide an auditable and accountable decision making process
Contractors and consultants alike are always found in larger numbers when large IT projects are running, this is because the organisation:
a) does not have the staff numbers to resource internally
b) does not have the skills to resource internally
c) must be held accountable for all decisions, processes and work that is delivered
d) has a limited funding model (even if it is in the billions of dollars) so must have expendable resource
e) has usually not undergone a project of such magnitude with the chose technology or in the chosen environment
f) must continue "Business As Usual"
Contractors provide the man power and the technical skills where as consultants provide the guidance / advice and accountability and traceability that is required. Without either groups large projects would not be possible.
The largest, recurring issue that surrounds the projects that you so quickly judge and dismiss is the organisation itself. Large organisations, in particular government departments are change adverse. No matter how much they need to change, how clearly the senior executive articulate benefits and the "bigger picture" (if they even have it) the largest issue is instigating and successfully executing culture changes.
Government departments are so entrenched in doing it the way its always been done, and not upsetting the status-quo that they hinder and block the process the entire way. If you want to see more successful projects that deliver and come in under budget and time then you should first look at your peers and other permanent staff before you start laying judgement on contractors and consultants.