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.

What is a risk and an issue- Layman Terms

This may be very obvious to someone up to speed with Project Management speak, but it can be a bit of a mystery for those not.

The other week I heard an excellent analogy which makes it crystal clear.

If you are walking down a street and there is a pile of dog muck in front of you there is a RISK that you may walk in it, if you actually step it on, boy you do have an ISSUE.

In another every day scenario, when you are planning your holiday and you have a flight at 9, and you have to travel on the M25 you have a RISK you could miss your flight, if you then miss your flight you have an ISSUE.

You will often hear talk of mitigating risks, in the holiday example a good mitigation would be to book a hotel the night before so removing the risk of travelling on the M25.

Hope these everyday examples, help breakdown some of the project management lingo.

Please leave any comments particularly for any other subjects that could be demystified.

Who is important on your project

Stakeholder Matrix

In your initial project planning session you have identified your stakeholders, what you need to do next is to evaluate their importance and influence on the successful delivery of your project.

To do this I use a simple 4 quadrant matrix, which evaluates the stakeholder in simple terms, this is an activity you should do at the start of the project and then evaluate regularly as you go through the lifecycle of the your project, as you will often find new stakeholders come into play and need to be managed.


The Matrix



How to use the matrix

Look at all your stakeholders, and evaluate where they go

High-High A good example here would be your sponsor (note here if your sponsor doesn't have high interest you are in trouble.

High Interest- Low Influence Could be team members you are relying on to complete a task

Low Interest -High Influence Influencial person in the business but not close to your project, for instance finance director who holds the purse strings.

Low Interest-Low Influence Most interesting category as you could argue why are they a stakeholder if in this category, a good example here could be your IT department who you will need to find that elusive bit of kit but claim they need a 3 month lead time.


Key Uses of the Matrix

Governance

From your evaluation you can see who you would need to include in your steering meetings, regular working groups and in any weekly updates.

Communication

On a project I am currently working on, it has a long lead time and on my monthly review I noticed that I had no communication with a High Interest-High Influence stakeholder for the last month.

On evaluation they are still key to the project success, so it was a good reminder to drop them a note with a quick update and explain why they hadn't had the expected involvement just yet.

Summary

Stakeholders and their support are paramount to the successful delivery of your project, and this is a great tool to initially manage them and then continually evaluate them.

Project Planning- The Quick Start

One of the most exciting things of being a project manager is when you have a new project starting from scratch and you need to get a good understanding of what you need to do and how you are going to deliver it.

There are lots of methods that you can use, my preferred method is a very basic rapid planning tool.

Some methods suggest getting all the stakeholders together and creating the project framework as as a group. I prefer a smaller group  of the obvious key stakeholders and subject matter experts in their field to start and aim to cover off 6 key components.

• Desired Outcome
• Purpose of Project
• Stakeholders
• What do we need to do
• Constraints
• Timescales 

Desired Outcome

It may be strange but it it always good to check and document what the desired outcome of the project is, sometimes stakeholders are not sure other times they may vehemently disagree on what the project is trying to achieve.

Purpose of the Project

As with desired outcome it is is always good to clarify, the project may be designing a new product but is the purpose to generate new sales or provide a vital add on for the existing product set.

Stakeholders

Many a project has been sunk by not involving the correct stakeholder early whose backing you need or may have some vital information that could have saved you a ton of time and money. You really need to be exhaustive in this process and don't just leave it to internal stakeholders, the need to engage with third parties is also key particularly in technology projects.

What do we need to do

The obvious key part of the project, as the project manager you will be completing a detailed plan to cover every moving part of the project, but it is a good idea to get a view of what needs to be done at the very early stage, this is also good for helping the stakeholders come up with a realistic timeline for completion of the project.

Constraints

The normal project constraints of budget, resources and technology will come up, but this is a good opportunity to identify constraints which can range widely from a key person being on maternity leave to a major migration project which the whole organisation has their eyes on.

Timescales

Sometimes these will be obvious such as mandatory change when legislation requires solution to be in by X date. However in lots of business driven change this will not be obvious, and some initial debate with the stakeholders over what is desirable and practical in terms of delivery date.

This session should taken no more than an hour and you should come away with some rich data to move your project forward.   

Taking over a project

One of the biggest challenges for a project manager, is to take over a project that has been running for a while, the high likelihood is that the project won't be in the best of shape, if it was in good shape you wouldn't be asked to take it over would you!

The first thing to remember is to have no pre-conceptions on what has happened before, take time to listen to all the stakeholders, find out what has gone well on the project so far and more pertinently what is not going so well. To take a learning from Stephen Covey, seek first to understand before seeking to be understood, you may well see very quickly where the issues are, and want to make immediate changes but these can be dangerous until you understand all the moving parts of the project.

It is unlikely that the project is stand alone and will probably sit as part of a bigger programme, so you will need to ensure you understand where your project sits on the critical path and where your dependencies sit.

Once you have grasped a good understanding of what is happening on your new project, share your thoughts and findings with your steering group, they need to appreciate the current position and validate they agree and support your initial findings and thoughts.

If the project is in a red status the Steering group will be keen to understand the plan to get it on track, be careful not to commit until you have all the facts, aiming to please the steering group early can come back to bite you.

The final piece of advice in your first weeks on the project is to build up incrementally particularly if you are asking the team to do different things, you can normally find something that can make the team's life easier and this will quickly get them on board.

Risks and Issues 

Why have Risks and Issues? 

The cornerstone to successfully managing your project is maintaining on a daily basis your risk and issue log, a good comprehensive list should take away the need for to do lists and then supplement all your reporting requirements both on an internal and external basis. 

It may sound excessive to review daily, but 5 minutes a day is far better than a tortuous 2 hour session every fortnight. It can then drive your to do list for the day.

What do you show your key stakeholders? 

Nobody likes to see a long list of risks with mitigation action points, for an executive summary you should concentrate on highlighting the top 5 risks, and where possible in a graphical format, I like to use the matrix shown below, with clear indication showing where your top risks sit on the matrix. A clear statement stating how many other risks you are managing is useful to give comfort that you are actively managing the risk log.

 

How to rate your risks?

I use the above matrix  but replace the words for numbers which translates into medium = 3 so a medium probability and a medium impact would gain a risk rating of 9, this is particularly useful when you are tracking movement in the risks, it is far easier to track a risk moving from a rating of 15 to 9 rather than moving from medium/very high to medium. 

What is the difference between a risk and an issue?

To be honest it doesn't really matter as long as you have it logged and you are actively managing the item. The general rule of thumb is that a risk is something which might happen whilst an issue is something that has happened. 

You can also have duplicate entries on both your risk and issue log, something may be live and you are dealing with it today, but particularly in a large complex project, an example is around communication, there is a high likelihood that you have an issue following a communication, but with many more communications planned for you need to have them clearly marked on your risk log.

Steering Packs

What makes a good steering pack 

The steering meeting is a very important part of any project governance this is your chance as the project manager to formally get direction for your project and approval for your efforts and progress so far.  
It also allows you to align all of the stakeholders, you have many discussions and views during your project lifecycle but this is the opportunity to get everyone aligned.   
  

• Be clear in what you are asking for

Time is likely to be constrained and you will only have limited opportunity to get across what you need, so make it very clear at the start of the pack the key issues and questions that you need to ask and get agreement, if you put this later in the pack the steering group will get distracted by data and probably exhaust the available time on trivial matters rather than confronting the issues you need to address.

• Keep the information clear and concise

The best way to avoid distraction is to keep the information very clear and concise use bullet points with minimal text and try to use pictures and diagrams where possible.

• Ask what the Stakeholders want to see

You can spend hours producing a wonderful pack which you are very proud of, but then you are left doubting if anyone ever actually reads what you have produced, it is definitely not  a weakness to ask a simple question on what your stakeholders want to see in the pack, if you do get the stock answer  "everything is fine as it is", complete the review yourself and start to leave bits out, sometimes the best way to find out what people really want to see is to take something away, then they tend to shout! 

• Get it out nice and early

To give yourself a chance of getting a good productive steering meeting, is to get the pack out nice and early, there is nothing more frustrating than receiving meeting documentation 10 minutes before the meeting is about to start, one of the key benefits of getting the pack out early, is that you can get some early questions/ clarification points raised early this helps you understand the priorities of particular stakeholders and with some quick action potential conflict could be avoided. 
It is also good to get the pack out on a Friday, at the end of the week the number and pace of meetings tends to drop so even if your pack doesn't get read immediately then you stand a good chance of it going into the weekend reading pile.
    

• Show that you are managing hygiene factors

Nobody is denying that plans, budgets and RAID logs are an important part of your project framework but the executive have employed you as a competent project manager and unless you require a decision these should run in the background, include them as an appendix if they are required but you need to again ensure that you don't lose valuable steering time debating if a risk rating is correct or if a milestone should be moved forward or back a day!

• If the sponsor cant attend reschedule

Steering by default has to have the sponsor in attendance, the meeting loses all effectiveness without as the attendees start to speculate on what the sponsor may want to do! If the sponsor cant find the time for Steering or keeps cancelling either find a new sponsor or project!