project headed for disaster

Project headed for disaster?

I want to take a different perspective on one persons perspective of a project headed for disaster.

An article titled ‘7 signs your project is headed for disaster’ specifically discusses ICT project failure and I was interested in the way that it looked at each of the seven signs.

Here is my view on each of the Seven signs your project is headed for disaster:

1. Whose idea was it again?

I am in complete agreement with what is discussed in terms of the project needing a Senior Business Sponsor. You must have both the business and IT in sync.

What is interesting is what I see happens regularly, where there is a Senior Business Sponsor, and IT take control of the project as if it’s their own, forgetting in the offset that the outcome and reason for the project is ALL business driven.  Yes, IT or ICT are the enablers to make the system (project) happen, but if the business didn’t have the need, then the project wouldn’t have occurred in the first place.   So, is it an  ‘IT Project or Business Project?‘.

2. Hey, can you do this for us?

I find the discussion here interesting. The article talks about outsourcing the work but retaining the responsibility.  Where is the project management here?  Why is the project not properly being managed by a Project Manager – especially a business Project Manager with a stream for IT, where there is an IT stream lead who is responsible for managing any external vendor who is delivering components of the project.

If the project structure is following Prince2 methodology, then this should present as an issue.

If the correct project governance procedures are in place, then again this should not be an issue.  There is no reason why if “the project is business critical [but] the IT department’s playing bridesmaid to a third party who’s calling the shots.

Sounds like a case of very poor project management to me.

3. All hunky dory here!

There are a couple of items here which I want to discuss further.

Firstly I agree with the comment “If you have a large project and everyone says it’s going well, across the board, all the time, be afraid,”.  This is a sure sign that red flags are up for any good Project Manager worth their salt… UNLESS they are managing things well.  I have had person experiences where I have been able to tell the Senior members of the PCB that everything is going well, because it honestly is.  Why?  Because everyone is working, issues are being raised and dealt with properly, risks are being logged and mitigated, the timelines were realistic, and delivery is being closely monitored and anything that might cause trouble dealt with straight away, so that slippage does not occur.

The other point around morale in the team is an interesting topic.  I have personally found that where communication, and I mean, open communication, is lacking morale is low.  If team members feel that they know and understand things in an open and honest way, then they are more happy to work in the team, with the team and be part of the ultimate delivery.

I’ve seen project managers who are ‘too busy’ to communicate with their team members and this causes disaster.  I also, often see project managers who have meetings with individual groups within a whole team, and not the team as a whole – again disaster.  The best way to deal with project issues, from my own first hand experience, is to have as many of the team members as possible in the one room together for a project team meeting.  Why?  Because it fosters collaboration, communication, awareness, and openness that otherwise would not exist if each stream,  or sub group were working alone, isolated from the whole.

4.  Let us know when you’re done …

I agree with the approach here, but again doesn’t it come down to ‘GOOD PROJECT MANAGEMENT‘.  Project phasing/staging, whatever you choose to call it is an integral part of good project management, and project management methodology.  And, it shouldn’t matter if you are using Waterfall or Agile, testing at each stage boundary should be a large part of your project planning.

What’s wrong that the Project Managers aren’t scoping this sort of process into their project planning?  Is it that they don’t understand?  Is it that they don’t allow enough time in their estimates for this to occur – that’s a problem in itself.

Again, the focus here is on a Project Manager truly MANAGING or LEADING the process.  There are a lot of project managers that really don’t know and understand what this means – which does set things up for failure.

5. Wouldn’t it be nice if…

What a classic example of where proper Business Requirement delivery would fix the problem here.  Most projects DO NOT start with fully defined and scoped business requirements and what a mistake that is.

IT customers (the business) usually don’t completely know what it is that they want or need.. until you start asking the tough questions.  It is far better to ask these tough questions BEFORE the project starts, than part way through.

A prime example of this was a system build project that I managed.  We did do the work to properly define business requirements, including what was mandatory for Phase 1.  This meant that IT had a complete and thorough, easy to use scope document from which to build the system.  Did it mean that the business got more than they requested in the first phase because the build could do things in a way that meant that certain functionality could be incorporated without blowing the timeline – Yes.  Did I end up with very happy customers when the system was delivered – Yes.  Be smart – take the time to document and get sign off of properly scoped and detailed business requirements (both functional and non-functional), it will be worth the time spent, in the long run.

6. Another week, another whip-round

This is an interesting topic – project team churn.  I’ve had very little trouble with this on the projects that I’ve managed and I believe that it comes back to my discussion earlier about open communication and creating a ‘one-team’ work ethic.

If you have a team member, or team members who are working tirelessly to make things happen, when others in the team are working against them, holding up delivery, causing issues that can’t seem to be resolved, just not playing nice, then it’s more than reasonable that the people working hard would want to leave.

But, if on the other hand they are part of a team where

  • they ‘feel’ part of a team, where everyone is working towards the same end goals;
  • everyone is dealing with issues as they arise to solve them;
  • they are rewarded for achievements;
  • they gain support when they need it,

then it will make a huge difference to their willingness to go the hard yards and be there till the end;  to see that finished product/system/change implemented.  They’ll want that feeling of success, just as much as the other team members.

The Project Managers ‘management’ style plays a huge part here, and many get it wrong.

7. Welcome aboard

I agree with the comments here.  If possible you need to have project team members come along for the total ride.. not just dumped into it when the going gets tough and you need work completed quickly because the delivery has slipped.

In the past when I’ve had teams working, I’ve engaged other team members and had them participate in team meetings along the way, so that they are fully across the project, and not just bought in at the time when they are expected to deliver.  That way they get to better understand the whole picture, and not just their little part of it; they also understand any dependencies and can raise issues up front, so that, again, everyone knows what’s going on and no one is in the dark.

Scheduling can be a huge problem.. and project managers really need to have a good handle on this from the on-set so that they are putting out realistic schedules so that the problem described in the article shouldn’t be occurring.

This post is my personal comment on the article  titled ‘7 signs your project is headed for disaster’ from the Sydney Morning Herald.

Karen

Written by Karen Munro