Tag: Project Management

Project Management – the practise of ENSURING SUCCESS. See this selection of Agile and Generalist Project Management templates and articles.

Posted on by

Roadmap Project Template

Roadmap Project Template

We have been creating Roadmap Project Template designs since the early 2000s. Our customers include all the top consultancies, and professionals across over 190 countries.

Our History with Roadmap Project Templates

We first started creating Roadmap Project Templates in the early 2000s in the media industry. Our formats quickly became popular as a simple way to communicate strategy and project plans.

Why does the Roadmap format work well?

The Roadmap format is so effective because it enables your readers to see the whole story within minutes! You can see the timeframe, the key project elements, the risks, the milestones, and any important moments AT A GLANCE. A good roadmap can be read within 3 minutes.

Roadmap Project Template: in early 2000s

While the format remains the same – the timeline, workstreams and milestones – this roadmap format is considerably closer to 1990s design.

Portfolio Roadmap Template (Visio)
Portfolio Roadmap Template (Visio)

Then in 2010

As we left the 2000s, it became popular to include a dashboard and dials in your roadmap. This meant the presenter could report on project plans, and current status, within minutes. All in one screen!

The Powerpoint Roadmap + Dashboard communicates Product Status at a glance
This Powerpoint Roadmap includes a Dashboard to communicate project status at a glance.

Our formats in 2019

As we reach present day, the formats become more contemporary. This Hack Event Roadmap (for Hackathon planning) has more of an infographic style.

This Roadmap Template is used for Hackathon Event Rollout.

Find out more

See our range of Roadmap Templates here
Posted on by — Leave a comment

When a Project Goes Wrong, then Stop; Breathe; Plan a positive review

Argghhh – the Project has GONE WRONG!… too often we freak out in an self loathing, whining mess. Especially when there’s more than one team involved. OK.

OK. Take a moment. Stop your teams from running around in circles and screaming.

We usually forget the good things! And,… there will be good things again.

Take a breath, and plan a “Lessons Learned” Project Retrospective:-

  1. to put things back in balance,
  2. to establish what needs to be done differently next time,
  3. to emphasise what was great about the project,
  4. to draw a line under the project so that negativity can’t damage us any further, and
  5. to get the teams talking again.

One tendency though, is that negativity can be brought into the Lessons Learned session.

So – how do we keep the Lessons Learned Positive and Productive?

Getting the Right Facilitator is really IMPORTANT!

Important attributes for your Facilitator:

  1. Neutral – was not directly involved in the project
  2. Positive – is self-starter, positive and always pushing for the best
  3. Pragmatic – has a grip on what is feasible and reasonable
  4. Some sense of humour – sees the humorous side of things
  5. Has knowledge of the area – understands the business in question

A good Facilitator must:

  1. take all points as valid, and record them carefully
  2. prevent defensive behaviour – “it’s happened, let’s get this point recorded”
  3. prevent arguments or tempers from flaring – “we’ll record everyone’s points – they are all now valid – remember the Prime Directive :)”
  4. keep track of time – be sure that everyone is getting their opinions in, and that noone is allowed to monopolise the available time
  5. encourage insights from quieter participants – there are likely to be dominant characters, so make sure the quieter ones get a chance to share
  6. be fair, and praise contributions – keep the atmosphere positive and light by being fair, listening well, and giving praise to brave or focussed insights

Focus on “How to do better next time”

Focus on “how to do better next time” rather than “Who got it wrong / what was wrong this time”.

Use Norm Kerth’s “Prime Directive”

Norm Kerth’s Prime Directive is generally accepted as a great way of staying positive in your retrospectives :

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Set out your Lessons Learned Agenda

You can use this Agile Lessons Learned template as a good basis and structure on which to build.

This helpful Agile Lessons Learned Template lays out a good framework for your session, and includes helpful notes for the facilitator, guidance, and mistakes & pitfalls to avoid!

[purchase_link id=”2246″ style=”button” color=”blue” text=”Add the Project Lessons Learned Template to Cart”]

  • Make it short and clear.
  • Set the times for each section.
  • Prepare the room for what’s going to happen.
  • Stick to your times.

Further help with your Lessons Learned Session

You can find a complete guide to how to run an Agile Lessons Learned Project Review here.

More Project Review and Lessons Learned Templates

Pods Embed Error: Pod not found.

Posted on by — Leave a comment

What is a Project Roadmap? Roadmap Basics for Beginners

What is a project roadmap?

This guide will explain the important parts of a Project Roadmap. It includes workstreams, activities, timelines, risk levels and other elements needed for an effective project roadmap.

What is a Project Roadmap used for?

1. Quickly communicates project plans and goals.
2. Manages stakeholder expectations.
3. Generates a shared understanding across the teams involved.
4. Communicates plans with other important teams/organisations.

What is a Project Roadmap?

It is a simple diagram format, that shows your project plans over time. Step-by-step Keynote Roadmap Template Example
IMPORTANT: A Project Roadmap IS NOT the place for detailed project plans and detailed information.

What does a Project Roadmap include?

1. Must Have: The Project Goals articulated; at least in the deliverables listed.
2. Must Have: A timeline – to show when things will happen.
3. Must Have: The high level titles for the big deliverables (don’t get into the detail!!).
4. Should Have: The workstreams in separate “Swim Lanes”.
5. Should Have: Milestones of key events, when you expect them.
6. Could Have: Areas of high risk.
7. Could Have: Areas where you have dependencies.

What are the Key Characteristics of a Project Roadmap?

It gives a sense of the Project Goals: Either explicitly in plain words: “The goal is …”.
It shows the plans for a project in simple terms: not too detailed – just the high-level titles! (keep to 4 or less in each workstream).
It fits on 1 side of paper (or 1 slide in a presentation) to keep it simple!
It shows project plans alongside a timeline.
You can read it and understand it in 3 minutes or less.
It avoids acronyms and team jargon, so that anyone can understand it!
It has your name on it – so people can contact you with questions.

What’s the best Project Roadmap presentation?

The best project roadmap presentation is one that tells your story simply and quickly. You must give a sense of time, the important project elements, and any key messages you want to highlight.
What is a project roadmap?

Step-by-Step guide to creating a Roadmap

See our Creating a Roadmap guide here.

Creating a Roadmap can have useful side-effects

The process of creating a roadmap, with key project stakeholders and team members, can be a very useful exercise for your team, because it:-

  1. Ensures that the team and stakeholders understand capacity
  2. Forces priority decisions
  3. Promotes a shared understanding in the wider team

Roadmap Examples and Samples

Posted on by — Leave a comment

Managing Stakeholders in Agile Projects

Managing Stakeholders in Agile Projects can be tough in large or old organisations. Have you heard this: “YES. We are agile. But you must tell me what I will get and when!” It’s painful.

The natural tension between Agile and Senior Stakeholder Structures

Upper management in large organisations and Programme Management structures (e.g. PMO) have a natural conflict of interests (or ‘tension’) with agile principles – i.e.

  1. Management and PMO want details on what is going to be delivered and when – i.e. Definition Up Front! – and
  2. The Agile product delivery team want to adapt and change dates and features as & when the customer/audience change – i.e. Definition When it’s NEEDED!

Addressing the tension – how to run Agile in large Stakeholder structures

So – how should we approach the comms around an Agile Project / Programme, and stakeholder management?

The Powerpoint Agile Roadmap Dashboard slide shows project status + Roadmap
The Powerpoint Agile Roadmap Dashboard slide shows project status + Roadmap

Clear “Release” / “Goal” Planning

  1. Describe your Releases (i.e. the significant product drops / deliveries) clearly
  2. Provide a clear 1-sider about each release, outlining what the business goals are

Manage expectations with “The Cone of Uncertainty”

  1. For each aspect of the release, clearly define the expected variance of estimates, according to degree of certainty
  2. So, if you have allowed e.g. 2 sprints / iterations for a feature, but do not plan to unpack the user stories until later on, assign an appropriate +/- 40% caveat to the estimation
  3. For more info
    1. see Agile 101’s understanding the cone of uncertainty.
    2. or Wikipedia’s entry on Cone of Uncertainty.

Focus on Epic User Stories / High-level Features

i.e. use High Level Requirements (EPICS / Features / Themes) to define the delivery

  1. Do not break down your Epics / Features into user stories unless:-
    1. They are about to go into iteration, or
    2. They are very high risk or unknown, and you can’t attach any estimation.
  2. So – avoid breaking down the WHOLE delivery into User Stories.
    1. It is in direct conflict with Agile and Lean to invest in definition unless you NEED to.
    2. So – only spend the teams’ time on defining user stories at the point of implementation.
  3. Keep these high level requirements flexible – this gives you agile wiggle room and scope flexibility at the point of implementation.
  4. Estimate the Epics in Story Points or T-Shirt sizes.
    1. See estimation recommendations here from Agile 101.

Keep Progress Clear

  1. Update your stakeholders regularly on where you are with Features / Epics implementation.
  2. Use a simple format (e.g. Release Plan) to explain which workstreams are delivering which features, and when.

Excel RAID Log & Dashboard Template
Excel RAID Log & Dashboard Template

Run a High-Level RAID Log and reference your Epics

  1. Use a RAID log to speak in Senior Stakeholder ‘lingo’.
  2. Keep this light, and do not go into too much detail.
  3. Update each sprint, or as serious RAID changes emerge.

Leave room to manoeuvre within your Epics

  1. When defining your high level features or “Epics”, keep the scoping high-level.
  2. Be clear and strategic about the scenarios and success criteria.
  3. Assign risk information to your Epics – raise stakeholder awareness of which features are risky / giving issues.
    1. This will enable them to help you prioritise.
    2. In healthy organisations, this provides a diologue in which to descope and reprioritise high level features.

Include High Level “Non Functional Requirements” (NFR s)

  1. Be sure to include any significant NFRs.
  2. e.g. (and not limited to-) :
    1. Ingegration requirements.
    2. Load testing, User testing, Stakeholder Acceptance testing requirements.
    3. Performance testing.
    4. contingency for all of the above.

Communicate Agile Plans to Senior Stakeholders

Here are some reporting formats that you can use to communicate Agile plans to Senior Stakeholders:

Posted on by — Leave a comment

Define your Product Rollout Plan

The Rollout Plan Template - Powerpoint Presentation
The Rollout plan Powerpoint Presentation

Planning your Product Rollout is crucial. You need to design the workstreams, and put project controls in place to be sure your rollout stays on track.

[purchase_link id=”2080″ style=”button” color=”blue” text=”Download the Rollout Plan NOW”]

You can see our ready-made, tried-and-tested Rollout Plan Template here.

How to Plan your Product Rollout

Define “Success” – Your Rollout Objectives & KPIs

  1. What does success look like? – you must document this with measurable success criteria.
  2. Once you have this, you can identify some points in the rollout when you expect to be able to measure the “Performance” of the rollout.
  3. You can record these as Milestones, and as KPIs to focus the team on.

Understand your Risks, Assumptions, Issues and Dependencies

  1. In order to ensure the best possible rollout, you to understand what might affect your success negatively, and manage each of these factors.
  2. In project management terms, this is your RAID log, and includes documenting and managing your:
    1. Risks
    2. Assumptions
    3. Issues
    4. Dependencies
    5. View RAID templates here
  3. Track, mitigate and manage your RAID items through the Rollout process

Define your Phases & Timeline

  1. With the above points in mind, set your timeline for the Rollout.
  2. Base the timeline on a realistic and achievable timescale, and with your RAID items in mind.
  3. If it makes sense to the whole project, split your timeline into Phases, and name them

Define your Milestones

  1. Along with your KPI points, set milestones so that you can monitor project progress
  2. Be sure to get regular Status Updates, and ensure the wider team and stakeholders get Status Reports

Set out your Workstreams & Project Activities

  1. In Agile projects, and in larger Programmes, your team and activities should be arranged in Workstreams
  2. Each Workstream should represent a team, or a particular area of delivery; e.g. “HR”, “DEV”, “CATERING”, “FINANCE”
  3. Plan the project activities, and the KPIs out into these workstreams, along the timeline
  4. Ensure the Workstream participants have contributed, and helped form each workstream plan

Communicate your Rollout Plan!

  1. Agree the Timeline, Workstream, KPI and Activity plans with your team
  2. Create a Rollout Plan Presentation, with your team
  3. Present to all teams and stakeholders
  4. Give your team and Stakeholders Status Reports frequently throughout the Rollout

[purchase_link id=”2080″ style=”button” color=”blue” text=”Download the Rollout Plan NOW”]

Business Documents UK Rollout Templates

[downloads tags=”193″ buy_button=”no” price=”no” number=”12″ order=”ID, DESC” columns=”2″ pagination=false]

 

Posted on by — Leave a comment

Project Plan

Powerpoint Project Plan Template

The most effective Project Plan presentations are individually tailored for your audience – one size does not fit all. Browse these plan formats.

Project Plan Template showing a 2 year timeline, workstreams and milestones
An example Project Plan – showing 2 years timeline in a roadmap format; milestones and workstreams

Your Project Plan – Who are you showing it to?

Be very clear about your audience – you will need different project plan approaches for each scenario:

  1. For executive audiences use a Roadmap format to show project plans: Powerpoint Roadmap Template, Visio Roadmap template.
  2. For Product Manager audiences, you should use a Product format: Powerpoint Product Template, Visio Product Template.
  3. To show your product team workstreams what they are doing, use a Project Plan Template format.
  4. For your developers, you should have a release plan, showing activity per iteration.

Some Agile Release Plan Formats