Showing posts with label teams. Show all posts
Showing posts with label teams. Show all posts

Friday, 12 March 2021

Learn from Lean: use Collaborative Design for faster and cheaper projects

 When should a project manager plan to use the project budget? Should you keep a lot of budget in reserve for the last part of the project, to fire-fight problems? Intuitively, the answer is YES.

But the answer from Lean is NO. You should invest up-front in Collaborative Design. You will have fewer fires to fight. This article explains why.

Collaborative Design in Lean Manufacturing

Lean Project Management is based on Lean Manufacturing. Lean Manufacturing was pioneered in Japan by Toyota and Honda. Collaborative design was an integral part of the success of Lean Manufacturing.

It’s often hard to transfer concepts from Lean Manufacturing to Lean Project Manufacturing. But in this case it’s easy, because Collaborative Design comes from Lean’s new product introduction: for automobile manufacturers, introducing a new car is a project. Toyota and Honda pioneered Collaborative Design to optimise their project success.

It’s explained in the excellent book The Machine that Changed the World : the Story of Lean Production by James Womack et al.

In the best lean projects, the numbers of people involved are highest at the very outset. All the relevant specialities are present, and the project manager’s job is to force the group to confront all the difficult trade-offs they’ll have to make to agree on the project. As development proceeds, the number of people involved drops…

In many mass production design exercises, the number of people involved is very small at the outset but grows to a peak very close to time of launch… to resolve problems that should have been cleared up in the beginning.

The budget is spent very differently in Lean: it’s spent upfront. Whereas in Mass Production, it’s saved for downstream trouble-shooting.

Let’s draw this as a graph. Let’s compare two projects which have the same budget in man-days (effort). We see that the two graphs of effort against time are very different.

Collaborative design in lean manufacturing

Collaborative Design drives project success. The authors quote some figures:
  • cheaper: a nearly two-to-one reduction in effort
  • faster: a saving of one-third in time

Collaborative Design in Project Management

Let’s bring this back from automobiles to project management.

A lot of projects follow the same curve as Mass Production. Planning is largely a solitary activity, mostly done by the project manager. Resources are added down-stream to firefight problems late in the project.

Collaborative Design brings together the key stakeholders (such as work package owners, subject matter experts and users) ...

Read the rest of the article here

  •  to see other comparative graphs 
  •  understand the three features of Collaborative Design

Monday, 24 September 2012

Why a project manager is like the conductor of an orchestra

Here’s an incredibly easy question that many people get wrong.

Question: What is a project manager? 
Answer: Someone who manages a project.

Many projects and many companies get this question wrong. They don’t understand the project manager role. They think that the project manager delivers the project. They think the project manager is a “doer” not a manager.  They hire technical specialists as project managers and ask them to get stuck into the technical work.

Let’s be clear: The project manager’s role is to MANAGE the project. He or she is primarily a manager. Any technical expertise is useful but secondary.

Prince2 is clear about this. Prince2 has a well defined project organisation, in multiple levels

    1.    At the top level is the Project Executive (sometimes called Project Sponsor or Project Owner) and the project board. This is the level which takes decisions and assumes accountability.

    2.    In the middle is the Project Manager, who manages the project day-by-day and coordinates the specialist work.

    3.    At the third level are the Project Teams who do the specialist work and need technical expertise.

For Prince2, the project manager is like the conductor of the orchestra.
    •    The conductor doesn’t make music;  s/he coordinates the musicians.
    •    The project manager doesn’t deliver the project’s work;  s/he organises the work

For Prince2, a key task of the project manager is to package up work and give it to the teams.

It’s like a handshake. We need agreement between the project manager and the team manager on the work to be done

    •    The Project Manager proposes a “Work Package”
    •    The Team Managers proposes a Team Plan to deliver the Work Package

Once they are agreed, the work can start.

And once the work does start,  the project manager has to follow up on progress.  The project manager has to MANAGE progress, without being too “hands-on” nor too “hands-off.”

    ❑    If the project manager is too hands-on, s/he wastes time (and often ends up doing the work rather than managing it)
    ❑    If the project manager is too hands-off, s/he may lose control (and fails to manage)

To manage correctly, the project manager should review the work package status regularly at periodic “check-points”. A check-point isn’t a long and boring weekly status meeting. Prince2 avoids “management by meeting” which is time consuming and ineffective.

A check-point is a regular event, typically weekly.
    •    A written status report
    •    A meeting (optional)
    •    Follow up

A check-point should always start with a written status report. It’s important that the status report is written, and it’s important that the project manager gets it before the meeting. This allows the meeting to be a short-and-sharp meeting - the Project Manager can focus on a few key points from the written report. This is “management by exception”, which saves time and helps to ensure that the Project Manager is focused and effective.

The team’s checkpoint report is structured into
    •    what the team has done in the current week
    •    issues
    •    what the team expects to do next week.

Let’s look at an example. Perhaps a team manager sends a Check-point report every Thursday to the Project Manager. On the Friday, the project manager might discuss with the team manager (face to face, or by phone, by instant message…):
    •    two tasks which were not finished on time
    •    one issue which looks worrying
    •    one task which must be planned for next week

The Project Manager focuses on a few exceptional points rather than on the broad status. It’s management by exception. The Project Manager is a manager, and doesn’t need to control everything in fine detail. In some projects, the Project Manager may need strong technical expertise in order to define Work Packages; and may even directly manage one or more teams. But the key task for the Project Manager is to manage.

So now we have the right answer to the question “What is a Project Manager”. The answer is simple with Prince2. The project manager is … a manager.

Monday, 13 August 2012

Aim high to build a high performance team


In today’s fast moving world, most organisations have a large change agenda. Do you have more projects to run than people to run them? Are you forced to use inexperienced staff to run key projects?

One response to this challenge is to look at best-practice frameworks like Prince2 for Project Management, or MSP for Programme Management. But it’s important to set the right goal.

When you start to deploy a best practice framework like Prince2 or MSP for your team or company, you should set the goal high. You want a high performance team, not just a few star performers. If you create team-wide strength in project management, you can really start to deliver your organisation’s change agenda.

Some organisations hesitate to standardise on a framework like Prince2; perhaps they train a few people, but they don’t roll it out to everyone.

They are missing the benefits of a generalised solution. The way to get full benefit from a framework like Prince2 is to generalise its use.

There are three reasons why you should widen the rollout of a framework like Prince2 or MSP:
1) each framework is relatively simple to learn so training is short and relatively cost effective
2) a framework provides a single point of truth to unite the team
3) a framework helps your organisation to improve and innovate.

Let’s look at those points

1) Speed: Learn in a week

All the best practice frameworks  from OGC (Prince2, MSP, MoP, P3O, etc) are reasonably simple to understand. With a week’s training, you can understand the key concepts, pass an exam and get a basic understanding of how to use the framework.

At the team or enterprise level, this means that all your team can learn your method. You can train them all. This is a key to success.

2) Single point of truth

If your organisation uses a framework such as Prince2, you have an external reference.

There are thousands and thousands of books on Project Management. Every author has his or her own ideas. If you don’t have some reference point for your organisation, every Project Manager will have his or her own ideas.

Prince2 has condensed a huge diversity of opinion into one book, which covers a major part of Project Management. That means that an organisation which adopts Prince2 has started to simplify its Project Management problem. With Prince2, you start to introduce a single vocabulary, a single point of view, a single intellectual framework. That’s significant added value, and a second key to success.

3) Improve and innovate

Don’t be worried by Prince2’s apparent complexity. Treat it like a supermarket which stocks 10,000 items, but you only need a week’s groceries. It up to you to choose. You can adapt Prince2 to your needs. This is what Prince2 calls “tailoring”.

If you tailor Prince2 with intelligence, it becomes a springboard to innovation. It becomes easier to implement, easier to use, and easier to adapt to your business needs.

You should start with the standard framework of Prince2, then simplify in order to implement it. If you hit barriers to implementation, then simplify it further. (That’s quite normal - the first simplification is never quite enough!). This simple core is your starting point. It’s your foundation for building team-wide high performance.

As you continue, you can build on this foundation. You have focussed on the essentials of your project management problem. You have  a basis for continuous improvement, for further innovation. And that’s your third key to success.


That’s three keys to success to building in-depth strength, and a high performance team. You need to aim high to increase your project capacity, and to meet the challenge of delivering an ambitious change agenda. Aim high, deliver high performance.

Wednesday, 28 April 2010

Lean: multi-functional project teams

Lean or not lean? I'm struggling to get multi-functional teams working in our programme. Today, our programme organisation mirrors the current business teams (the BAU "silos"). In the coming months we have some major deliverables to produce, where all functional teams must cooperate. With today's organisation, the teams can't readily plan their work, as they each have a silo view - they are highly dependent on other teams for scheduling and decisions, for inputs and outputs.

The lean approach is to maximise cross functional team work. Each multi-functional team can then work back from the deliverable due date and manage its own work plan. The cross functional team produces a single, unified deliverable. It has its own internal communications (meetings, chats, virtual spaces...)

That's lean project management.