Politics

Interesting point came out this week, the project I am managing was in trouble on three fronts, but the sponsor was keen that only one was emphasised  with the key stakeholders.

I tactfully presented all the issues to the stakeholders, and what was perceived as a big issue did not come across as one at all with the stakeholders.

The key to this successful meting was in the preparation, by producing a clear concise slide deck before hand, which not only outlined the problem areas but sought to understand the potential knock on effects, it allowed all issues to come out in a structured manner and reduced time in trying to understand what could happen.

The outcome was a quick successful meeting, with a revised delivery plan in place.

Most people are not looking to dwell on what has happened, but prefer to focus on putting it right and delivering the right thing for the business.

Breaking down Project Management into the very basics

Even something as simple as driving to the shops can be converted into a project lifecycle:

Scope- What I am going to buy

Budget- I have £10 to spend

Timeliness- I need to be there and back within an hour to pick the kids up

Risks- The traffic could be bad, I might not get a parking space

When working with new project managers, I like to set a task, which is outside of their core area of knowledge, as I work in Financial Services, I use a simple construction task, of building a new shed.

In the project sponsor briefing, this gives the new project managers plenty of opportunity to ask the right questions to establish the scope, typical questions would include

• Size of shed
• Colour of shed
• Location of shed
• Any additional requirements (electrics etc)

The good part of the task is that there are no real constraints so it can be as simple or as complex as you want it to be.

From the scope the aspiring project managers, then put the plan together, again this is a fairly simple exercise and no one in the real world would try and put a shed up without buying the materials or digging the foundations, but these things can get missed when putting your plan together, which is an excellent discipline to encourage that everything is documented.

The other key learning from this exercise is that once you start to put a plan together it can rapidly change as you start to assess how all the components need to hang together.

The final part of the introduction, is to start to introduce the concept of risk, both documentation and mitigation, the biggest risk with this simple construction task is the weather, which can lead to some interesting mitigation ideas. 

Project Manager- Expert Danger

A question that always gets discussed is how much technical knowledge a project manager, my view apart from some extreme cases where you need a deep technical understanding such as engineering, the project manager to perform their role effectively needs next to little to deliver successful projects.

Working on the assumption that the PM is relatively intelligent (and to be qualified they would be) they would be able to quickly build a good general understanding of most industries and organisations.

The skills that the project manager brings in identifying and facilitating stakeholder discussion, formatting plans and then driving through delivery should outweigh the skills of a product expert.

So what are the dangers if you do have a project manager who is an expert in the area of delivery

OFFERS OPINION ON DELIVERY

Once a Project Manager offers an opinion on delivery, they start to come part of the solution, they should allow the sponsor and the key stakeholders to agree the project objectives and success criteria.
Getting to involved at the start threatens the PM's independence particularly when difficult decisions may be needed or when a full and frank review of what went wrong is required.

PICKS UP KEY DELIVERY TASKS

There will be always the temptation if dropping behind the plan for the PM to pick up tasks themselves to keep the project on track. This will inevitably lead to the core project tasks getting neglected and as with offering opinion on delivery there is a clear clouding of roles and responsibilities in the project delivery.


ASSUMPTION OF KNOWLEDGE

When you as individual know something there is always a tendency to assume that others have the same level of knowledge, and key needs such as communication and training can get overlooked. Having knowledge also loses the PM ability to ask stupid questions, which are always great to make sure everyone understands what the deep geeks are talking about.

PROJECT NEVER FINISHES

If the Project Manager is an employee rather than a contractor, the chances are that as an expert they will continue to work in the area, where the danger is that the project manager will continue to be involved in whatever has been delivered, and effectively causing the project to never finish!

Handing a project over

It is always nice for a project manager to see a project through from inception to delivery in reality this doesn't always happen many things can happen such as prioritisation or a new job for the incumbent project manager.

I always find handing over hard, and the main thing that you always need to remember is that it is not personal, I was always told not to fall in love with your project and that becomes more pertinent when you are handing it over, a new project manager will always have a different way of looking at things, and will interpret what you see as an issue as a risk and vice versa.

I break the handover in to 5 stages:

Stage 1

To make the handover as simple as possible the best method is to meet face to face with your replacement and talk them through high level what has happened so far, what the success criteria is and what has gone well so far, and where you see the challenges, this gives them an overview and some things to think about before you move on to the next stage.

Stage 2

Handover the governance providing plan,RAID logs, governance schedules and previous steering packs, to end this stage you should create your own governance document outlining how you are going to handover and what the key deliverable you need to complete to ensure the new PM has everything they need.

Stage 3

Introduce the new project manager to all the key stakeholders, do the initial introduction and let the new PM get to know the stakeholders and their thoughts on the project.

Stage 4

A week or two shadowing is useful, but both you and the new PM need to review this, as the new PM will be champing at the bit to get going and you will find it odd and maybe frustrating when you are not running the show anymore.

Stage 5

Provide ongoing consultancy, where possible provide support and consultancy where asked, but only when asked, the new PM is driving the project and you wouldn't like it if someone kept interfering with your new project.


As with all aspects of Project Management the secret to a successful handover is communication.

Lessons Learned and Wash Up's

Project delivered what happens next

When a project has completed there is still things to do, both for the ongoing development for the business that you are delivering for and for your own personal development.

All good project management books will tell you about the formal project framework requirements of closing a project although you will find it difficult to get engagement once a project has been completed, as the natural order is to look back rather than forward. However I firmly believe that to keep innovating you need to learn from things that don't go smoothly and to plan.

This week I have completed two different wash up activities, whilst both looking back at project delivery they serve different purposes one to help with strategic direction for a next phase of integration and the other to identify how a process improvement can be implemented better.

Executive Summary

A 2 page summary highlighting the following:

What the issues were

Solutions for the next stage

Working at this level, no need to go into detail, remember the sponsor should be aware of these issues and this is a recap. If you have kept a good RAID log through the project this activity is relatively easy to put together.

Detailed wash up

This activity brings together all the stakeholders who have been involved in the project and runs through the following themes:

Communication of project strategy and deliverable

Testing Procedure and feedback

Process Improvements

Actions to complete before fully BAU

From the wash up this week, there was an obvious problem identified as it was clear that the senior management who had signed off the change had not clearly communicated to the users what was happening and why, a vital lesson learned for my next project.

Assumptions- Be Careful

Introduction

It is important to document and get agreement of any assumptions that you make on your project, and it is absolutely essential when dealing with external stakeholders, particularly when providing professional services.

I generally find there are two types of assumptions that you need to document and be aware of resourcing and technical decisions.

Resourcing

At a start of a project there is a lot of excitement and promise of great resources that will be at your disposal which allows you to build a great project plan, however experience shows says this does not always follow through, particularly when the sponsor's next exciting project comes along.

Resource is always a big issue on any project and you need to fight hard to keep good resource.

Technical Decisions

A couple of examples here are when you are putting your business case together and for example you are offshoring some activity, you will need to document and agree that you are moving roles on a like for like basis, getting this understood and agreed early saves surprises for everyone later on.

In your technical planning you could make an assumption that your changes will be able to go into the standard release programme, change release managers are very protective of their schedule so again book your assumption in early.

Process

You can't totally guard against an assumption not being correct or agreements renegaded on, but to mitigate i carefully track the assumption agreed in a project meeting and then play them back in an email to the manager responsible, then add to them my RAID log and then perhaps more importantly check in on a minimum monthly basis to ensure the assumption still holds good.

Comments/Future Articles

It is nice to be getting a steady number of page views, I would love some comments good or bad and any ideas for furure articles

Getting close to delivery date

Unless your are very lucky, the normal scenario in any technology project, that when you are getting very close to the deadline day there will be still a lot of tasks to do and very likely there will be lots of pressure on achieving the target date.

Very often the target date will have customer implications or cost implications if it is not met.

As the project manager you will probably be under huge pressure, but you must ensure that the last minute chaos does not compromise all the good work that you have done so far.

Here are 5 things to remember when you enter this period:

Replans and Timescales

The easy tasks have probably already been done, the straightforward test, the simple code or the basic job descriptions. Remember the last tasks always take longer than you think so plan and communicate accordingly.

Cutting Corners

Or to use its project language title de scoping, there will be the inevitable request from either the sponsor or steering group to see what can be dropped from the remaining project tasks. If you can it is a good idea to create a separate work stream to manage this activity including the documentation that de scoping will bring such as manual processes or new change requests. If you fail to document a key stakeholder will claim they were unaware of the decision or implications of the de scope.

Stay Firm

You know better than anyone else how your project is ran, how hard your team are working, as you reach the critical phase, lots of suggestions will be made on how to finish quicker and meet the deadlines, depending on the seniority of the stakeholder some will need investigating, however be firm and back your team, making changes at a late stage rarely pays dividends.

Other Workstreams

Make sure you keep up to speed with any other Workstreams in your programme, if they are also struggling with the deadline date, if gives you leverage in your planning, and it is good information to communicate to your team so they know they are not alone in being up against it.

Prompt communication

Make sure that any issues or risks that occur are communicated immediately at this time waiting for a formal governance structure is to late. Quick responses to progress requests also give assurance that you are in control.