A decision log is simply a list of all the key decisions made on the project.  It includes:

• A reference for the decision
• Date decision made
• What was agreed and why
• Who agreed to it
• Where you can find more information or supporting documentation (optional)

This is better explained by a screenshot of a decision log:

A decision log is better than keeping discussions on email or in another enterprise collaboration tool.  All the answers you need and the justification about why those decisions were taken are all in one place.  The decision log can solve many project disputes, especially when the team is working on a project that involves changes to strategy or approach or has a long duration.

Just because something is on the decision log does not mean it is written in stone.  When key members of the project team change, or a new sponsor takes charge, you can review the decisions to date and check if they are all still relevant.  If not, reverse or amend the decision – but make sure you record why this was done and who authorised it.

You may already have a similar thing included in your meeting minutes.  Project managers sometimes record a summary of actions and decisions at the bottom of their meeting minutes.  This is a good habit, but it does mean that you have to look through a lot of minutes when you want to review the background to a decision and can’t remember when it was taken.  A decision log keeps everything in one place and makes it easy to review what was agreed when.  It’s a useful tool for managing disputes, and if you append it to the meeting minutes everyone has an up-to-date record at all times.  I encourage you to try it on your projects!

Related posts:

1. Making Good Project Decisions
2. Communicate, communicate, communicate
3. Making Good Project Decisions – Part 2

Related posts brought to you by Yet Another Related Posts Plugin.

To start, Rich Maltzman, PMP presents Zero is the new Infinity posted at Earth PM, saying, “Green is the new black, and zero is the new infinity…” He also writes his own blog and posted We just ain’t that good at risk from Scope crêpe, saying, “Really – we aren’t.”

Valery Zelixon presents Supplier selection process part 1 – - how to select global supplier for your business posted at Supply Chain Notebook.

Stuart Corrigan presents How To Map A Process posted at Vanguard Scotland, which also includes some links to free tools for process mapping.

Guru presents 25 things that you need to know to host successful events posted at Eventzilla Blog. This is on the boundaries of project management, but if you are hosting lunch-and-learn sessions for teams of project managers, courses or simply workshops for your projects, review this list.

Wise Bread presents How to Get Your Boss to Let You Work From Home posted at Wisebread.

Bruce Loflland presents Hidden reasons why things don’t get done posted at PM Technix.

And here’s another from Rich Maltzman, PMP presents Green Project Management and the BP Deepwater Horizon Spill posted at Earth PM. “Pertinent!” he says.

Chris Solomon presents Project Management Tools Part – 1 Critical Path Method(CPM) posted at Jazz Presentation, saying, “Critical Path Method is A very effective Method used in Project Management to Segregate the most important parts of the projects for the rest.” This is a basic article on critical path method.

And finally, here is a new project management blog: IT Project Blog.  Not very adventurously named, but it looks like it could build into a good resource.

That concludes this edition. Submit your blog article to the next edition of carnival of project management using our carnival submission form. The next edition of the Carnival will be hosted at A Girl’s Guide to Project Management.

Related posts:

1. Carnival of Project Management #33
2. Carnival of Project Management #30
3. Why critical path is critical to project management

Related posts brought to you by Yet Another Related Posts Plugin.

The ants are supposed to represent a case study in organisational structure.  It’s an interesting idea, and I suppose it might get a few more people along to City to find out about their graduate degrees in project management!  Has anyone passing through Tacoma actually seen it?

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. City of Seattle Department of Transportation Expands Use of Construction Project Management Software from Meridian
2. Kaplan University Students Bring Project Management Lessons to U.S. Food Banks
3. SaaS Aids IT Project Management in Washington

Related posts brought to you by Yet Another Related Posts Plugin.

A Blueprint is a detailed vision for the organisation, covering what the organisation will look like when all the projects are completed, the programme is wound up, and the business transformation is done.  Typically, you would only write a Blueprint at programme level, so project managers will ‘inherit’ a Blueprint from their programme manager.  If you are leading a project as part of a bigger initiative being managed as a programme, ask to see the Blueprint if you haven’t already.  It will help set your project in the wider context of what the business is trying to achieve.

In particular, Blueprints use the POTI model as a way to define the scope of what is going to change once all the projects in the programme are complete.  POTI sets out the scope of the programme at a high level.

POTI stands for Processes, Organisation, Technology and Information.  These four areas make up a comprehensive view of all the elements that form the programme scope.

Processes

Projects change processes and introduce new ones.  This area of scope covers any operational business models that will change as a result of the work that will be carried out under the programme.  This can include:

• performance levels and output
• the introduction of new ways of working
• the phasing out of old ways of working
• changes to existing ways of working

Organisation

This area of scope covers the people changes that will result from the projects.  This is a broad section and it covers everything to do with personnel from organisational culture to how many employees the company will need when the programme is complete.  Examples of items that would be included in this area of scope are:

• new skill requirements for employees
• culture changes
• staffing levels
• employees moving from one role to another
• training needs

Technology

Technology requirements for the programme fall into this area of scope and will typically be delivered across several projects within the programme.  This area, however, covers more than just computers.  It also encompasses systems, tools and other resources such as buildings.  The sort of things that are included in this scope area are:

• new computer systems
• changes to existing technology systems
• accommodation requirements – procuring or selling off buildings
• machinery or heavy plant requirements
• other equipment needs – procuring or selling off equipment
• new networks or toolsets

Information

This final part of scope covers the mainly intangible area of data.  Information required in the new, fully transformed, organisation is noted here.  These changes can be hard to establish at the beginning of the programme, so your scope statement may just say ‘new information requirements’ and these can be defined as stakeholders are engaged throughout the various projects and their reporting and information needs become known.  As some examples, here is what you could include in this section:

• new reports
• changes to existing reports or reporting systems
• requirements for new data to feed into reports
• project-specific data outcomes like occupancy rates if you were building a new hotel

You would expect to see something in each of these four categories as part of the scope statement in the Blueprint.  It will be very rare that something will be delivered without having an impact on all of these areas in some form, so if you are writing a scope statement and have some pieces missing, think again about what will be changing as a result of this transformation exercise.

While POTI and the Blueprint as a whole are generally used for programme management, there is no reason why you couldn’t adopt the POTI model for use on a project to help you define the project scope.  What do you think?  Would you use it?

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Book Review: Project Governance
2. What is PESTLE?
3. The SIO Model

Related posts brought to you by Yet Another Related Posts Plugin.

Delegation and escalation are two sides of the same coin. Delegation is giving work to someone in your team or maybe on the same hierarchical level as you. Escalation is giving work to someone above you, such as the project sponsor. The same principles apply for both task allocation exercises. The person receiving the tasks needs:

• Clear instructions on what to do with it
• A deadline by when you need it done
• An appreciation of what will happen if it doesn’t get done i.e. setting the task in the wider context of the project.

How do you choose which tasks to delegate, which to keep, and at what point things are escalated? You’ll have to do all of these things in a ‘normal’ project, so it is worth spending some time to work out how to get them done. This could involve:

• Setting tolerances for tasks and decisions: what are the trigger points for escalation? What can you fix yourself and what or when do you need input from someone higher up the project hierarchy?
• Establishing what the staff development needs are on the project: who on your team would like some exposure to quality reviews, for example? Could you plan for them to be involved in quality reviews as part of their on-the-job training, with a view to delegating them the task of quality reviews in the future?
• Establishing how competent your project team members are: what can you delegate safely? An enthusiastic member of staff might be really keen to take on the job of updating the project plan, but how well do they know Project Planner, or your project scheduling tool? Enthusiasm isn’t a suitable reason for you, as project manager, to delegate tasks. Prepare to support your team member through the learning curve so that she is competent as well as enthusiastic about taking on new responsibilities.

As we’ve seen, the project tolerances provide a framework to establishing which tasks need to be escalated. Set project tolerances for time, cost, quality and anything else you can think of that is important to the stakeholder group.

Some people find it easy to escalate but not so easy to delegate. If that sounds like you, remember a time when someone gave you a piece of work to complete. How did they do it and what instructions did they provide? If delegating makes you feel uncomfortable, just practice how you do it. You can’t avoid delegating, so you might as well think through how you will go about handing off pieces of work to your team, and if you need to, run through what you are going to say in the privacy of a meeting room or on your way to work before you talk to them.

Finally, consider how you will go about delegating and escalating. When is a good time to hand off tasks to a colleague? Do you need to schedule a meeting with them? If it is your project sponsor and the escalation is urgent, are they easy to get hold of? If not, what’s the contingency plan – or do you have to put everything on hold until they are in a position to provide some feedback as a result of your escalation?

Delegating and escalating are things that will come naturally, once you have been a project manager for some time. However, with a new team it is always worth consciously thinking about how you will make these things happen so that you get good results from delegating and escalating for your project and your team.

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Skills of a Successful Project Manager
2. The Quality Management Plan
3. The SIO Model

Related posts brought to you by Yet Another Related Posts Plugin.

There are four categories of stakeholders, which provide a starting point for your to brainstorm all of the relevant parties involved.  The four categories are:  users, governance, influencers and providers.  Let’s look at each of those in a bit more detail.

Users
These are the people who will use the products of your project or programme.  They are the beneficiaries of the outputs.  For example, these could be customers or another internal department.  In the case of delivering a new software package for your Sales team, the users would be the Sales team.

Governance
These are people or groups of people who have an interest in how things are managed on the project or programme.  For example, management boards or steering groups would fall into this category.  Auditors, regulators, health and safety executives would also be categorised as governance stakeholders.

Influencers
Influencers are the people who have the ability to change the direction of your project or programme.  An example would be the local newspaper in the area where your project will be building a new facility.  Trade unions and lobby groups are also influencers.

Providers
As you would expect, suppliers and vendors fall into this category.  Providers can be wider than that, though, and include business partners, temporary contractors, catering staff, and anyone else who provides resources to the project or programme.

There are many instances where an individual or a group would fall into more than one category.  Staff could be both users and influencers – especially if you were surveying them about their training needs for example, and then shaping the programme as a result of the findings.

You can also break the categories down, which is especially useful in the case of the users.  You could split this into internal and external users, or Marketing and Customer Service users, or part-time or permanent users, or any combination that makes logical sense to you.

The purpose of categorising stakeholders is to be able to provide them with targeted communication regarding the project or programme, so break down your stakeholder groups into meaningful groupings related to shared interests.  Use a mindmapping tool like DropMind to capture the output from your stakeholder mapping, and move the groups around until you are happy with the outcome.

Try to keep the groupings at a practical level.  It is not helpful for your communications plan to have ‘members of the public’ but it could be useful to have ‘members of the press covering the area around where we are building a new factory’.

The easy way to remember these four categories of stakeholders is by the acronym UPIG:  users, providers, influencers, governance.

If you are interested in where this fits within MSP, it’s in the Leadership & Stakeholder Engagement governance theme.

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Managing stakeholders: 6 steps to success
2. Book Review: Project Governance
3. Don’t forget these stakeholders!

Related posts brought to you by Yet Another Related Posts Plugin.

It’s not that unusual.  Stakeholders at executive level change frequently.  From time to time the board will move responsibilities for certain initiatives around between themselves.  You might find that your project is now the responsibility of the marketing director instead of the sales director.  Or that something previously sponsored by finance is now sitting with the VP of Product Development.

Executive stakeholders can also change due to redundancy or through the post holder finding a new career opportunity.  On a long project, you should expect a certain degree of change.  And the more senior the stakeholder, the less notice you will get about the change.

Are you ready to induct a new stakeholder at a moment’s notice?  If all your project documentation is up to date it should be relatively straightforward.  However, bringing on board a new stakeholder is not without challenges.

For example:

• How much does the new stakeholder know about the project?
• How much do they care about the project?
• How much do they intend to change the project’s deliverables?
• Do they understand the change management process?
• Have they ever been involved in a project before?
• How do they like to receive project communications?
• How available are they going to be to you and the project team?
• How much involvement do they intend to have in the day-to-day running of the project?
• How much influence do they have over other, existing stakeholders?

A new stakeholder will need to slot into the existing structure.  A new project sponsor may well have different views about the objectives and deliverables for the project. Let’s look at both in turn.

A new stakeholder

As you did at the beginning of the project for the original stakeholder base, conduct a new stakeholder analysis.  How has the new stakeholder changed the dynamic of the project?  Where do they fit on the stakeholder management grid looking at interest and influence?  Once you have established their position and relative influence over the project, you can start to develop a stakeholder management strategy – again, as you would do with any stakeholder at the beginning of the project.

Spend some time with your new stakeholder to get to know them and to bring them up to speed with the project so far and what is expected of them and their team (if anything) as the project progresses.

A new sponsor

Initially a new sponsor may not want to change anything, but once they have led the project for a while they may start to introduce some changes.  Ideally, these should be adopted (using the formally change control process) if possible, but you should take the opportunity to explain to the new sponsor at what point it is no longer possible to make certain changes.  Take them through your project plan, and ensure they understand how to read the Gantt chart in Seavus Project Viewer or whatever tool you use.

Show them previous steering group reports and check that they are happy with the format, and their role as new chair of the steering group.

Hopefully you will have some handover between old stakeholders and new, or the old sponsor and the new sponsor, but in real life that isn’t always possible.  A short handover meeting might be all you get, or you may not have anything at all.  Try to spend a bit of time with the old stakeholder – even if you have to do so without the new stakeholder there.  Find out what outstanding actions they had, so you can pass these on to the new team.

On long projects it is almost inevitable that one of your stakeholders will change.  When this happens you need to be ready to react accordingly and bring the new stakeholder up to date as quickly as possible to make them an efficient and useful addition to your stakeholder group.

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Managing stakeholders: 6 steps to success
2. Communicate, communicate, communicate
3. Achieving Stakeholder Satisfaction Through Project Control

Related posts brought to you by Yet Another Related Posts Plugin.

Being able to group projects and programs together means you can then make decisions about them – decisions that can affect budgets or staffing levels for the work required, as well as which areas to focus effort on to meet the company’s strategic objectives.

Portfolio management is the way in which you manage and make decisions about groups of projects and programs.  It’s a strategic role – but if you don’t think your project sponsors have got their heads around it, ask the PMO to get them a copy of An Executive Guide to Portfolio Management, which has just been released by the OGC.

Project portfolio management provides the opportunity to look at projects and programs and work out where to make investment decisions.  You should be able to take the company’s overall strategic objectives and map these back through the different levels to any given project task – portfolio management provides a structure to be able to do that.   Typically, project portfolio management looks at how projects are resourced and costed, which provides executives with data around project teams, budgets and expenses on projects, and the project and program deliverables.

You could keep track of your portfolio in something like Seavus Project Planner, but many companies opt for more sophisticated portfolio management tools.  If you are in a small company with only a few projects and maybe one or two larger programs, you may find that portfolio management is too unwieldy to add much value.  It tends to work better with companies with large resource pools, as it can help avoid duplication and will ensure that effort is focused on the most effective solutions.

Even with a small group of projects or programs, you can still apply some of the fundamentals that underpin portfolio management:

• Make decisions based on data, and have a clear decision making process.
• Make sure the outcomes of decisions are communicated and are understood at all levels within the project organisation, as well as the reasons behind those decisions.
• Be transparent – make sure that decisions tie back to business objectives.

Ultimately, the purpose of portfolio management is to get consistent decision making across the organisation that ensures a focus on the right projects at the right time.  It’s particularly useful in making investment decisions.  Where are you going to spend all that money?  Make sure it goes to the right projects.  Unsuccessful initiatives are stopped; project teams work on what is going to provide the most value for the company.  And everyone understands why they are doing what they are doing.

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Key Characteristics of Enterprise Project Management
2. Book Review: Project Governance
3. The SIO Model

Related posts brought to you by Yet Another Related Posts Plugin.

MOST stands for:

• Mission
• Objectives
• Strategies
• Tactics.

As you can imagine, this can apply to pretty much anything and it lends itself very well to setting project structure.

Mission

Start with setting your mission for the project.  What are you doing, in one sentence?  Using a tool like Seavus DropMind can help gather all the ideas and words to then filter out the key messages and form a mission statement.  Mission statements are typically broad, and focus on values.  You might use your corporate mission statement for your project, or there might be a program level mission that you can inherit.

Objectives

Your project only has one mission, but it will likely have several objectives.  What are they?  How will your project be structured to support them, both in terms of project phases for delivery and resources?  These are the goals for your project, which are supposed to tie directly back to helping you achieve the mission.

Strategies

Strategies are how you are going to deliver your objectives.  For example, if the objective is to reduce the cycle time for customer complaints to 3 days, your strategies will be ideas around how to do that.  You may have several initiatives that contribute to meeting that objective.  These could have different workstream leaders or be championed by different departments.

Tactics

At this level you make your strategies real.  These are the tasks required to deliver on all of the above statements.  Where at the ‘strategy’ level items are owned by workstream leaders, here the tasks are allocated to resources who will complete them.

As with any model that has hierarchical layers, the key thing here is that all the levels support and build on each other.  You shouldn’t be working on any project task that doesn’t support a strategy, all the strategies should support the project objectives, and the objective should underpin the mission. This way it is very easy to see how what you are doing contributes to the overall goal.  People feel more engaged and empowered if they understand how their work makes a difference, and this is a good way of showing how everything links.

You don’t have to necessarily create a long document to explain all this – it’s something you could use during a kick off meeting, written up on a flip chart and then filed away.  It sets the tone, and is also useful when you come review the benefits that the project has delivered.  In fact, you might be using this type of structure anyway, but without calling it MOST.  Do you recognise this in anything you do today?

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. The SIO Model
2. Defining Strategic Projects
3. Key Characteristics of Enterprise Project Management

Related posts brought to you by Yet Another Related Posts Plugin.

The top post this month comes from Rich Maltzman, PMP, who presents What is Secondary Risk? posted at Earth PM.

Kathy C presents Project Based Learning Projects for Employees posted at The Thriving Small Business, saying, “Employees often learn better by doing. Developing a project based learning environment can benefit both the employee as well as the organization.” Too many ads on this site for my liking – try to ignore them.

John Hunter presents Frugal Innovation posted at Curious Cat Management Improvement Blog, saying, “Applying the ideas of disruptive innovation and appropriate technology lets you take a fresh look at what options you have. We often don’t give completely new ideas enough attention.”

Soma has interviewed Susan de Sousa on Stepping into Project Management.  Interesting interview, plus some tips for newbie project managers.

Bas de Baar has written New Trends in the Project Ecosystem, at Project Shrink.  Has the blog had a facelift?  It certainly looks good now!

That concludes this edition. Submit your blog article to the next edition of carnival of project management using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

PMtips.net is proudly supported by Seavus Products.

Related posts:

1. Carnival of Project Management #33
2. Carnival of Project Management #30
3. Driving Innovation

Related posts brought to you by Yet Another Related Posts Plugin.