Showing posts with label planning. Show all posts
Showing posts with label planning. 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, 22 July 2013

Time for timesheets.. or wait until tomorrow?

If you want to get control of your projects, you should use timesheets. Or should you? Is the accepted wisdom really wise?

Timesheets allow you to measure effort; i.e. man-days of work. All project management methods suggest you should control time and cost. Human effort one dimension of cost. It is normally expressed in man-hours or man-days of work (which usually can be  converted into a financial cost). To control effort, you need to estimate it when you plan and then track the actual effort. That’s where timesheets come in, to track the actual effort.

The Prince2 project management method follows this approach. The Prince2 planning process has an estimating step. For Prince2, effort is the primary resource estimation for each task. (Secondary resource needs include equipment, travel or money). By saying that you should control effort, Prince2 ask you to plan and then to track effort. Prince2 therefore assumes that you will use timesheets.

That’s what they are doing at one major bank using Prince2. Effort is indeed the main measure of project resource estimation. A small banking project may have a budget of 50 man-days of effort, whereas a large project may have a budget of 3000 man-days. To monitor progress, the bank uses timesheets to record actual effort by the project teams. So, for example, a 10-week project estimated at 50 days may finish with 45 (or 55 or whatever) actual days of effort. This is calculated from the timesheets of all the project team members submitted during the 10 weeks.

So timesheet solutions aggregate a lot of data from a lot of people. You need timesheet software, which lots of people need to use correctly and regularly. That’s where the problem starts. The software vendors will tell you that the software is easy to use (maybe true, maybe not!), but they won’t always tell you how much work is needed to achieve a sustained, widely-used solution which truly delivers benefits to your wider organization.

In some organisations, there can be hundreds of people working on various projects. A large hospital tried to implement a timesheet solution to control project effort.  Inside the IT department of about 50 people, this worked OK.  But most projects go beyond IT. The hospital has about 3000 staff, very many of whom could work on a project. You can’t ask 3000 people to fill in timesheets, just because some of them may work on a project from time to time.

Even for the small IT department, the hospital hit another problem, of scope creep. Once they had estimates of project effort for their teams, they had a partial forecast everyone’s future work plans. So they decided to go for a 100% solution, and complete the picture with plans on non-working time (holidays, etc.) and non-project work (support, maintenance, staff meetings, etc.). Once you try to manage the full working week for your entire team, you add extra complexity for little benefit. The hospital could not sustain the effort, and the timesheet solution failed.

There are a lot of failures with timesheet implementations. It’s hard work and there can be a lot of resistance. People don’t like filling in timesheets. It takes a lot of work to get everyone to submit a time sheet each week (and to sustain this 52 weeks per year). Furthermore, if you succeed, the data quality may be low, and consequently the benefits for project control may be slim.

Timesheets can work well in certain environments, for example where hours are billed to the customer. Or in closed environments, such as software development teams, where all projects are done by a limited number of project team members. In these cases, there is a clear benefit to the organization, so you can more easily succeed with timesheets.

If you choose not to implement timesheets, what can you do? One major chemicals company has decided not to use timesheets today for their projects. They know it’s premature – timesheets wouldn’t work today. Their solution is to track cost and time, but not effort.  Costs are tracked (expenditures); time is tracked (activity start and finish dates); but effort is neither estimated nor tracked.

So should you use timesheets? If your goal is to improve your team’s or your company’s project management maturity, yes, it should be on your long term agenda. Should it be a priority? You need to analyse timesheet deployment as a long term project. It’s not a quick-win software implementation project – you need sustained long-term commitment to get any benefits. Work out the business case, study the risks of failure.

You’ll possibly find that deploying timesheets is not a priority project. Your return on investment is perhaps too uncertain, your risk too high. Focus instead today on easier project management improvements with more certain benefits. Wait a while until you tackle timesheets. MaƱana, demain, morgen, tomorrow.

Monday, 21 May 2012

Why the Project Manager is a Time Traveller

In the popular Science-Fiction film, “Back to the Future”, a mad scientist makes possible time travel. Marty, the film’s hero, can travel to the future. In real life, we can’t travel to the future, but we often need to imagine the future.
The project manager (and programme or portfolio manager) is a change agent, who will change or innovate, to build a different future. The project manager’s job is to imagine a new future and how to get there. We travel to the future in our imagination.
So the Project Manager imagines the future, and converts it into a plan. A good project manager will spend a lot of time planning, which is almost “living in the future”
  • planning the journey to the future (how to get there)
  • planning the destination (what the future will be like)
The experienced Project Manager is constantly thinking weeks ahead … imagining what will happen next week, next month, next year. That’s a key characteristic of a good Project Manager.
Planning can be a major, time-consuming activity for the Project Manager. If done wrongly, the Project Manager can waste much time on planning, as one plan gets replaced by the next and then the next...
To plan effectively and avoid wasted time, methods like Prince2 (for Project Management) and MSP (for Programme Management) can help enormously.
Three key strengths of the Prince2 approach to planning are:
  1. Prince2 starts the planning process with Product Based Planning. You start with the “What” (your deliverables, which give a picture of the future) before the “When” or the “Who” (which tell you about the journey). Product Based Planning generates more robust plans, which are easier to understand and maintain.
  2. Prince2 has three levels of plan - project plan, stage plan, team plan. This reduces complexity, and aligns planning to the team structure.
  3. Prince2 uses just-in-time planning - as the next stage approaches, the stage plan is created. This avoids the need for a hard-to-build and hard-to-maintain mega-plan for the entire project.
MSP has a similar approach :
  • MSP separates the picture of the destination (the Blueprint) from the journey (the Programme Plan)
  • MSP has several types of plan - programme plan, project plan, transition plan… This is aligned to the programme organisation, and avoids building one hard-to-handle mega-plan
Planning is important. As project teams move to “light” forms of Agile, some fall into a trap. Essentially, they move to “discovery mode” and stop planning. The daily stand-up meeting can’t replace a plan, it’s too focussed on the present, not the future. Planning is not optional. As the old saying goes “If you fail to plan, you plan to fail”.
So make sure you are a time traveller. Spend time in the future, and build your plan. Then use it. As the other saying goes “Plan your work, then work your plan”.