As experienced change practitioners, I’m sure we’ve all worked on projects that have been difficult.  The unfortunate truth is that some projects gain so much momentum, they become “too big to fail”.  These projects steamroll their way through organisations, and have a tendency to displace anyone that dares to challenge them.

Sometimes when working closely on a project, it is difficult to see the warning signs.  However, it is worth carrying out a project “health check” every now and then, to check for danger signs.  If you see any significant warning signals, then you might need to take some serious (and unpopular) corrective action.  Five such signals are discussed below:Project Health Check

1. Experts are ignored:

Projects that are in trouble may choose to selectively ignore concerns raised by experts.  Inconvenient truths tend to be “parked” or “explained away” without further analysis. Even worse, the commitment of those raising the concerns may be questioned.  This tends to have an extremely negative effect – morale of the project team is likely to suffer as they don’t feel listened to.  And even worse, they may feel disinclined to raise concerns in the future.

Organisational solution: Organisations and projects should encourage their experts to speak up.  It is generally better to know the “cold hard facts”, and every member of the project team should be encouraged to share their constructive concerns. This issue will cease if an organisation proactively fosters accountability, whilst also fostering a culture of continuous improvement and learning. And remember: A project maverick is not a heretic!

2. Business cases are “re-worked”:

Business cases should be a central tool used by organisations to ensure that only profitable projects are run.  In some cases, other “hidden agendas” may be at play, and the project team might be asked to use some “creative licence” to make a business case look profitable.   This often happens in organisations where there is little accountability for the realization of project benefits.

Organisational solution: Organisations can stop this happening by encouraging and valuing true accountability, from project sponsor downwards.  The sponsor should be accountable for the delivery of benefits as well as the delivery of the project. Each project team member should be empowered to challenge decisions which seem to contradict the business case or scope.  Empowerment, accountability and integrity are the three key values that will prevent this situation from occurring in the first place.

3. Unclear objectives or scope:

One of the most serious warning signs on a project is a lack of scope.  If you start work on a project, and scope or objectives are not clear, then you are in for a rough ride.  This suggests that there has not been adequate attention paid to the foundations of the project, and in most cases it will be beneficial to step back and agree the scope.  If this doesn’t happen, there is a significant danger that the solution will be delivered in a way that does not meet expectations, and does not maximize return on investment.

Organisational solution: If scope or objectives are unclear, the only way to address this is to firm them up.  Good governance should stop this happening in the first place, but a project has slipped through then the project team should work to reach a consensus, and then move forward.  This might cost time in the short term, but it will save significant time in the long term, as it reduces the risk of misunderstandings and miscommunication over scope.

4. “Risks and issues” only exist on a log:

Embedding risk management techniques leads to more successful projects.  A significant project warning sign is RAID (risk, issue, assumption, dependency) logs that have not been maintained and are not being followed up.  This suggests that risk management is happening only “On paper”.   Each risk should be owned, and should have a defined strategy for dealing with it.  If this isn’t the case, then corrective action should be taken.

Organisational solution: The only solution to this problem is to ensure the project manager is actively controlling risks, issues, assumptions and dependencies.  If they are not, organisations should encourage and compel them to do so!

5. The project schedule doesn’t exist or is out of date:

A project and programme schedule should be a central communications tool.  Ultimately, this is a central tool that ensures everyone knows what tasks they need to complete, and what the deadline is.  A great way of carrying out a health-check on a project is to ask a random member of the project team where the project schedule is located, and ask them to show you a copy.  If they can’t, or if it is out of date, then you have uncovered a communication problem.

Organisational solution: Good governance and project discipline should ensure that all projects have a schedule that is fit-for-purpose.  Ask questions to ensure that a schedule is in place, and if it is absent then ensure it is created as soon as possible!

Conclusion

I see these warning signs as the “Big 5”, though there are many others that may surface on a project, and as change practitioners it’s important for us to recognise them and take any necessary corrective action.  Unfortunately, the corrective action is rarely palatable.  The most important thing we can do is to constructively challenge ourselves and our project colleagues, and ensure they are dealing with the cold hard facts.  We should escalate where necessary, and ensure that facts are not hidden and experts are not ignored.

Positive and proactive challenge and escalation is rarely popular, but is necessary to ensure that organisations get the best from their projects.  Good luck!

Have you worked on projects and seen these (or any other) warning signs?  Do you have any further examples?  I’d love to hear from you – feel free to contact me directly or leave a comment below.

Comments(1)TrackbackEdit

Defining business rules is really the bread and butter of business analysis. It is what we do and it is what we should do well.  Unfortunately I have spent a long time in this profession learning how to analyse and then present requirements, but until now I have not worked for an organisation or with a business analyst that uses a standardised approach to document business rules.

Thankfully I was bored one day and was trawling the Internet for Business Analysis techniques. This I admit was because I was at work and if they decided to monitor what I was doing online, at least I could argue it was work related!

Now when I am bored I confess that I have the attention span of a lobotomised gold fish with a hashish habit. This means that if I see a hyperlink I click on it. his approach usually means I become increasingly bored as I cycle from one dull article to the next, however this time I actually stumbled upon something quite useful. It was a website that provided free downloads that explained something called RuleSpeak.

 Suddenly I had two PDFs in front of me that made a lot of sense. Simple advice from someone that I now know is considered to be Mr Business Rules himself. Something so good that it gave me a method that I at the time I did not appreciate that was missing – a method of writing business rules in a consistent manner in a language that is understood by the business.

 Please follow the link to the site – it is worth downloading these PDFs and having a good read. Great advice and I strongly recommend that you consider adopting the approach.  http://www.rulespeak.com/en/

Comments(3)TrackbackEdit

It has always entertained me that when you get more than three business analysts in a room you invariably get different opinions about what makes a good requirement. I am a bit of a purist myself and go for the true business requirement, however a number of my more passionate colleagues argue the opposite and love to write requirements that in effect define the solution.

After a “heated debate” with a colleague one lunch time I started to understand why she felt that writing down a solution was what she called detailled requirements. It became apparent that she wanted to instruct IT to ensure that the “Business gets what they want”.

The argument is further enforced by the fact that “If I do not tell them specifically they come back and ask me what I want anyway. They never stick to the two week turnaround for a quote so I do not want to give them an excuse to blame me. It just saves time”.

Well I agree if you are going throw things over a wall and just expect an IT designer to magic up a solution design in two weeks with no contact then instruct away. I however hate this approach and it cannot be a coincidence that every failed project I have witnessed adopts this “(lack of) management” technique.

In fact the people in question that cannot stick to the two week turnaround and need to be given detailled solution instructions to operate are the same people that love to get pure requirements. Good, well written requirements that do not assume what the solution will be gives the IT guys a chance to actually show what they can do. Give them a chance to actually design a solution and potentially give you one or three options and most of them really shine and appreciate the chance to actually prove why they are in the job.

Work with them. Get them in a room or use video conferencing, Webex or other technologies to work collaboratively and also get the business stakeholders involved. Call it a JAD workshop or just a walkthough, but the important thing is to get the creative juices flowing. Each time I do that suddenly the IT guys "that always mess it up" actually deliver. They get a quote out in two weeks and because they have worked with me and the business to come up with their proposal, the business accept it.

I think personally do not think there is any excuse for presenting a solution as a requirement. That approach exists because there is no effective communication or collaboration going on in your project.

 

...sorry for being so quiet. As should become clear very shortly, we've been very busy.

Our free requirements management tool is just about to enter final testing and we're planning to release the beta version in early April. We really hope this proves useful so please keep watching the site for more details.

There will also be a lot of new website content coming soon which you will hopefully find useful. Finally, we'll spend a bit more time blogging once the tool is ready - so in short, do stick with us.
Leave a CommentTrackbackEdit