Should a Project Manager have any Red Lines?

I have heard from a number of fellow Project Manager readers of Be a Better Sheepdog comments such as "my organisation claims to follow a good Project Management standard but never in practice". I have worked with many client organisations and I can concur that I have never seen a standard or methodology implemented 100% and many fall way below that percentage! 

So this begs the question, should the Project Manager go with the flow or should he/she try and impose some Red Lines in how the Project is run? Red lines are common in negotiation and are points of no compromise. I argue for and practice a number of Red Lines which I describe in this article but also reveal where I am happy to compromise. I also explore some negotiation techniques which may be used.

To those that say "this is impossible in my organisation", I have a cartoon to repeat from an article on Project Manager Behaviours. 

My 3 Project Management Red Lines

1 - Have a real Sponsor or a proxy

It is not the job of a Project Manager to own the project, it is the job of the Project Manager to help shape the project and then run the project day to day on behalf of the Owner. My Sheepdog analogy is that the dog is working on behalf of the Shepherd to direct the sheep! 

So if not already defined, my Red line is to establish an owner I can talk with, work for and report to and will confirm things such as the Project Definition. Ideally I would like to find the real Sponsor (that is the person who ultimately owns the Business Case and realising the benefits of the project) and depending on the scale of the Project I may recommend the formation of a Project Board in line with good PRINCE2 principles.

But if this can't be achieved, I am willing to compromise with a suitable proxy for the real Sponsor. This needs to be a senior stakeholder within the organisation that engaged me. So in IT Projects where I practice, the real Sponsor is likely to be someone within the business organisation but I will typically be engaged by a senior stakeholder within the IT organisation. See this post on seeking out a Sponsor and potentially forming a Project Board. 

2 - Have some sort of Project Definition agreed by the Sponsor

If you are having some work done on your house, you are the owner and you engage a builder. Almost certainly there will be a contract between the owner and the builder. The same applies to a Project. So I will always produce a Project Definition of some form or other and seek the signoff of the Sponsor. This confirms that I have understood the Brief correctly and that the Sponsor understands the implications of the plan and budget I have proposed including agreement on what Success represents for the Project team. Remember the Kipling Poem when producing your Project Definition.

But I will scale this document to the scale of the project and the organisational culture. The form of the document is not a Red line for me. So while in one UK Government client I worked for I produced copious Word documents (PID, Stage Plan etc etc), there is no point in this approach if the culture of the organisation means that these will not get read properly. I am more interested in real review and agreeing key points. I often use PowerPoint for my Project Definition but have used email for small projects.

Of course, any contract needs to be signed off and this needs to be done in some auditable form, not verbally - remember what isn't written hasn't been said :)

Before signoff I will ensure that Sponsor understands the concepts of Change Management. As always, I find analogies can be useful in explanation "if you sign your contract with your builder and then part way through building works you change your mind, the builder will need to work out the additional costs and a new date for completion"

3 - Establish ongoing communications with the Sponsor e.g. Issue a regular status report

I'm afraid the challenges of Projects don't stop when the Definition has been agreed so I will want to ensure some ongoing communication channels to the Sponsor as Owner of the project and will want to establish this at the time of signoff of the Definition.

Firstly, I will always issue a regular status report to the Sponsor and other Stakeholders, typically weekly but it could be a different frequency depending on the circumstances. This is both good practice but helps in the process of ensuring ongoing engagement from the Sponsor. It is a formal way of calling for assistance or flagging concerns, remember some Issues are not solvable by the Project Manager alone.

However, if there are Issues I need help with or I am going to flag the Project as Red (not forecasting to meet agreed Success criteria), I will always contact the Sponsor with a verbal update such as a telephone call.

Lastly I will request a regular schedule of Project progress catchups, typically at least monthly. Again this maintains engagement with the Sponsor / Board and is a forum for raising points where assistance or guidance is needed before it becomes critical to progress.

Stakeholder understanding and Negotiation tactics

Always remember that the senior Stakeholders in your organisation may not have received suitable training and so may not understand why such points above are important. So the negotiation on your Red Lines should always start with reasoning and justification. See this article on helping your Sponsor understand good Project processes. 

Ultimately in any negotiation you should be prepared to walk away if your Red Lines aren't met. I still remember starting to walk out of a shop in Egypt because my Red Line on price was way off being met. Ultimately I ended up buying the item at an acceptable price because the owner knew I was serious. 

Back to the Project environment, I must admit to having an advantage as I am an external Consultant; it is far more difficult, maybe even impossible, for a permanent member of staff to "walk away". But I have always been prepared to agree to exit my contract should I feel that I am not in the position to really help my client deliver the Project. Interestingly, that situation has never ultimately materialised.

So good luck in trying to negotiate your Red Lines, it is better to have the painful conversations early and build from there :)