Need to deliver on time? Then start using time-boxes!

On time delivery is the El Dorado of project management. No one wants to be late for a key deadline. As the deadline approaches, and you’re running late, the project manager and the project team work like crazy to stay on time.  Everyone works late and comes in at weekends. This generates stress, overload, even burnout.

There’s a better way to deliver on time. It’s called time-boxing.

What is a time-box? A time-box has an fixed end date, which is fixed, but the work to be done is variable. If you are running late, you have a clear, pre-approved way of doing less. If you have less to do, you can probably get back on schedule. Before the time-box starts, you need to list the work to be done, and then get agreement on how prioritise it.

Here’s an example, for a simple project to tidy up and repaint a garage.

Without a time-box, you might list the needs in any order, perhaps in order of work
    •    Sort content of boxes
    •    Recycle junk
    •    Install new lighting
    •    Buy new tools
    •    Paint floor
    •    Paint walls & ceiling
    •    Paint woodwork

Without a time-box, if you run short of time, you may have to rush the last painting tasks. If you want to do a good job, you’ll be painting until midnight, and completely stressed out…

By using a time-box, you can keep calm and avoid panic. You will focus on the essentials, and make sure that those essentials are delivered on time.

The trick is, before you start work, you should get the time-box agreed. You need to prioritise the list of needs.

Prioritised list
     -- Must have --
    •    Paint walls & ceiling
    •    Paint woodwork
    •    Recycle junk
    -- Should have --
    •    Paint floor
    •    Install new lighting
    -- Could have --
    •    Sort content of boxes
    •    Buy new tools

 If we are a bit late, we will drop one or more items from the “could have” list. If we are seriously behind schedule, all the “could have” items and one or more “should have” items won’t get done. We will plan our work accordingly, with the the “must have” items early in the schedule and the “could have” items later.

The first time you use time-boxing, you might hit the problem that people can’t or won”t prioritise their needs. Your boss might say that everything is top priority. Nothing is negotiable. That’s normally not true, especially if on-time delivery is important. You may need to “educate” your boss. You may need to help people think through the real priorities.

If you are using a method like Prince2, you can add time-boxing to your work. In Prince2 terms, a stage or a work-package could be a time-box. You commit to deliver on time (zero tolerance on time), but you have a lot of flexibility on what you delivery, using your prioritised list of needs (so you have high  tolerance on scope)

Another choice for methods is to move to an Agile method such as Agile ATERN (with AgilePM certification), which is built around time-boxes and prioritised lists. This method  uses the acronym MuSCoW for Must have, Should Have, Could Have, Won’t Have to help you remember to prioritise.

So if you are always rushing to hit your deadlines, you have a better way forward. You have a way to avoid last minute stress and panic. If need to deliver on time, then it’s time to to start using time-boxes.

Project management, change management are like apples and pears

Should a project manager be a change manager? The traditional answer was YES, a project manager should know how to manage change. Today the answer is more often NO, as there are new and better ways to manage change.

Change initiatives are increasingly using a new role of Business Change Manager to manage complex change. In such cases, the project manager is no longer a change manager. Apples are apples and pears are pears: project managers manage projects. And change managers manage change.

What is wrong with a project manager running change management? Why invent this new role of Business Change Manager?

If we understand the Customer - Supplier relationship in projects, we will understand why. A Customer - Supplier relationship underpins most change initiatives: the project teams are on the supplier side, delivering a solution. The business teams are on the customer side, using the solution.

This “customer - supplier” relationship is not a question of contracts or invoicing. This relationship exists even for internal project teams working inside one company - an internal supplier provides a solution to an internal customer

This is why the we have two distinct roles, the project manager role and change manager role. One role on the supplier side, a separate, distinct role on the customer side.  And this is a peer-to-peer relationship, where the two roles are equal, not hierarchical.

Programme management methods like MSP (Managing Successful Programmes) recognise this separation. MSP has two two key processes
    ❑    a supply side process, called “Delivering the Capability”, for building the solution in project mode 
    ❑    a change management process on the customer side, called “Realising the Benefits”, for transitioning to the new solution and measuring the success of the change.

This approach has many advantages. Notably, it recognises that the motivations of the Project Manager and the Business Change Manager are very different.

The Project Manager is often motivated by
    ❑    technology (performance, features, innovation)
    ❑    sign-off and approval
    ❑    project performance measures such as finishing OTOB (On-time and On-budget)
   
The Business Change Manager has different concerns
    ❑    reliability, stability
    ❑    ease of use, training, support
    ❑    good documentation
    ❑    long term benefits

The Business Change Manager role needs business skill, rather than project management skills. The Business Change Manager should be chosen from the business area that will use the new solution. Crucially, after the solution is implemented, the Business Change Manager will return to the day-to-day business, and will use the solution week-by-week, month-by-month.

This reveals another important difference in motivation between the two roles the Business Change Manager (and his or her colleagues) is going to use the new solution, whereas the Project Manager will probably never do so. That’s a big difference, and that’s another reason why we we need a dedicated Change Manager.

So for your next business change initiative, try not to mix apples and pears. Don’t confuse project teams (apples) and business teams (pears). Project managers should manage projects. And change managers should manage change. Keep those apples and pears apart.