14 ways IT screws up projects
Summary: Successful projects require decent project execution. Look, no one's asking IT to save the world, but delivering projects really well should be a core IT function.
Successful projects require decent project execution. Look, no one's asking IT to save the world, but delivering projects really well should be a core IT function.
Some projects are so bad that IT seems to deliberately shoot itself in the head. Sorry, but I just don't get it.
If you disagree with this poor assessment of IT operations, then see CIO magazine's list of "The 14 Most Common Mistakes IT Departments Make:"
Staffing Mistakes 1. Projects lack the right resources with the right skills. 2. Projects lack experienced project managers.
Process Mistakes 3. IT doesn't follow a standard, repeatable project management process. 4. IT gets hamstrung by too much process. 5. They don't track changes to the scope of the project. 6. They lack up-to-date data about the status of projects. 7. They ignore problems.
Planning Mistakes 8. They don't take the time to define the scope of a project. 9. They fail to see the dependencies between projects. 10. They don't consider Murphy's Law. 11. They give short shrift to change management. 12. Project schedules are incomplete.
Communication Problems 13. IT doesn't push back on unreasonable deadlines. 14. They don't communicate well with project sponsors and stakeholders.
These aren't business-side issues; they're all well within IT's exclusive domain.
I'm always talking about IT/ business alignment, but maybe that's a mistake. When it comes to failed projects, maybe the hammer needs to fall hard onto IT directly: no excuses and no failures.
[Image via iStockPhoto]
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
I don't know where these 3 fit it, but they are
isn't quite scope (which is really about limiting the
requirements to be implemented), but way too many
projects are started without an unambiguous definition
of what has to be done. Business analysts, if there
are any, either won't or are unable to go into enough
detail leaving IT to define what has to be done.
Upper management is more focused on deadlines and
looks at queries for better requirements as a delay
tactic. And then guess what -- the [i]finished[/i]
project doesn't quite do what was expected -- big
surprise. And guess who takes the fall -- IT.
'without an unambiguous'
'Double negatives to little'
Also "Had to laugh" is poor grammar: try "I had to
laugh".
Sheesh...are you the misspelling grammar police that
uses poor grammar? Have you heard the saying about
glass houses?
Content v. typo, do the math.
# 15 - Play loose and fast with bandwidth
C'mon Mike, think of the poor ISPs who will ultimately have to meter access because of waste such as this. ;)
128k image?
You should work for MS
You could easily have used an image half that size or less, still gotten the message across, and been judicious with the usage of your viewers' resources. Anyway, back to your regularly scheduled topic.
Image size point
The final image file size is therefore dependent on the original image dimensions, size, and pixel depth.
Now, that's probably more than you wanted to know, but if you want further clarification then tell me.
What does this have to do with IT (specifically)?
The problem is trying to fit square pegs in round holes because you have a lot of square pegs, round pegs would cost money, and the square pegs would view it as an invasion of their turf.
Then why do so many projects fail?
They fail because...
IT: Ok, what do you want?
Mgt: I want you to tell me what I want but I don't want you tying up busy people and ask them questions. I also want you to do it without asking for any more money.
Management, by and large, doesn't know what they want, doesn't want to take the time to find out, and wants it yesterday, for nothing.
They are too busy to make time to tell IT what would save users time and money.
14 points or not, that's the bottom line. It's IT's problem, let IT handle it. And then blame IT when they fail to do "their" job.
My question is, how can anyone manage a problem when they have no clue what the problem might be?
RE: 14 ways IT screws up projects
Good to remind IT to look within and not always try to blame
themselves out of responsibility for what should be their
sweet spot.
Francine, you don't want him
Thanks for commenting and Tweeting!
Back with 5
1. Projects lack competent staff
Process Mistakes
2. Projects puts emphasis in the wrong areas (complete
specs when unobtainable)
Planning Mistakes
3. IT takes on too much at one time. Projects should be
broken down, emphasis on changing business process to
adapt them to existing IT solutions.
Communication Problems
4. IT doesn't involve users in testing and usability early
enough. Communicate the design and solution through
prototypes as early as possible.
5. IT doesn't understand the business task to change the
process (IT or user) to simplify it's solution for an IT
implementation.
From my experience IT projects head towards failure
because IT staff typically have a poor understanding of real
world problems/solutions and come up with extremely
convoluted designs. Such issues are easily avoided, but you
need the right staff (difficult).
"IT" versus "Business"?
Unfortunately, that reflects the reality in too many organizations, and that adversarial, CYA mentality is the meta-reason for many failures in software-intensive businesses.
Picture two people in a leaking boat. Business says to IT, "I"m sure glad the leak is in your end!"
www.ufunctional.com
Usually the Company as a Whole is Dysfunctional, Not Just One Dept.
I was a systems engineer in a company where product delivery and success depended on two engineering groups working well together. However, dynamics were such that one group would gleefully say "Ha! The problem was those guys' fault." When from the customer's point of view, product failings were the company's fault--- which it was.
Business is tough already without IT and business functions engaging in dysfunctional behavior. Business functions need to be clear about what they want and why it's important.
Likewise, IT needs to make it clear that they understand the business importance. They also need to make it clear why some issues are critical to being able to deliver what the business functions need.
Both sides need to be open to interim [i]working[/i] solutions that over time get you to where you need to be with less chance of failure.
My management knows way more than 15 ...
The beatings will continue until morale improves ...
Love this one
Similar experience
I appointed in his place.
Third party consultant was brought in to evaluate work
remaining. Furious activity for the consultant, Gantt charts
aplenty.
Finally a meeting was called to discuss the findings -
several man years remained and there was no hope of completing the project within the deadline (couple of
months). I asked what was the plan, the team responded
that this was a meeting to discuss the situation.
I left and returned to work, others remained to discuss the
dire situation. The project was completed on time, with
those contributing the least still in ranting it couldn't be
done. Strangely those weren't with me in the late hours or
weekends.
RE: 14 ways IT screws up projects