project management Archives - Page 2 of 3

Check-Point: Are you where you want to be?

Check-Points are a way of telling if your project doing well or badly and whether you are where you want to be.

People can become some wrapped up in what they are doing that they forget what is going on around them. Check-Points are and opportunity to review where you are.

If you were heading in the wrong direction, you would want someone to tell you?

Check-Points: One solution to this problem

One approach I use to address this situation is to have periodic “Check-Points”. A Check-Point is a quick review which is not directly linked to the project schedule. Regular reviews are best. You can have them at any frequency to suit your own needs.

Choosing the frequency of Check-Points is a matter of personal preference. Too frequently and you are wasting effort. Not frequently enough and you may “travel in the wrong direction” for longer than you need to. In my business I combine the Check-Points with the quarterly reports I produce for my investors, collaborators and colleagues.

The Check-Point should confirm that the objectives of the project are still valid. After all, who wants to have an on-budget, on-schedule project for superseded technology! It should assess where the project is relative to its objectives and it should assess the rate of progress and identify any issues. All of this should be done as quickly and with as little expenditure of effort as possible.

Plan your Check-Points carefully

Running a Check-Point should not be onerous. At its simplest it involves the Project Manager and a few other people and can be performed without disrupting the project team.

Confirm with the Project Sponsor (the Business) that the objectives of the project are still valid. After all, conditions in the outside world may have changed.
How much progress the project has made?
How much of the scheduled time has passed and how much remains?
How much of the budget has been spent and how much remains?
What is the rate of progress?
Are there any issues which are inhibiting progress?

If you are using one Agile project management, then you probably want the check-point to coincide with the end of a sprint.

Schedule a Check-Point

Why not schedule a Check-Point for your current project. Aim to answer the following questions:

Is the project still valid for the business?
Where are you? (And where do you want to be?)
Are you moving in the right direction?
Are you moving at the speed you want?

Bright Idea: Opportunity or Distraction?

Are you creative? Do you employ creative people? I like dealing with creative people, but we all know people who are always seduced by the next shiny thing they see. What do you do when someone comes up with a “bright idea”, a new way of doing things part way through a project? Do you adopt it or not?

This is one of those situations where you are damned if you do, and damned if you don’t.

What are the issues:

I expect that we want to achieve our objective and we want to do this efficiently.

We want to continue to make progress.
The “bright idea” may cause an improvement or it may not.
Implementing the idea will inevitably cause some disruption.
Even assessing the idea will cost some effort.

So, what should we do? – Change Management

The answer to our dilemma is to have some version of “Change Management”. We need to capture the “bright idea” and then assess whether it will actually help us and then, if appropriate, introduce it in a controlled way. We should also have some kind of back-out plan, so that if the proposed change doesn’t have the beneficial effect we hope for, then we can revert to doing things the old way.

The question is, “how do we do that?”

My suggested way of handling this situation:

First of all, you an agreed “Change Management” (in this case “suggestion management”) process. I prefer it to be as light-weight as possible. This should:

Capture the idea, so that it is not lost, even if it is rejected or not implemented immediately.
Encourage people, so they know their ideas are being considered.

Ideas should be assessed quickly, but without disrupting productive activity.

Here are some questions which will help you decide whether to adopt a suggestion and when to adopt it:

Can we continue to work doing things the current way? If so, perhaps we should defer assessing the change.
widespread is the effect of the change? Changes with widespread effects need to be considered more carefully.
Is there an obvious way of “backing out” the change?
Do the benefits offered by the bright idea justify the effort and risk to implement it?

Agile project management offers opportunities to incorporate change management and adopt bright ideas in a controlled way.

Scope: Are you trying to do too much?

Project Scope diagram — Set the Scope of your project

I don’t mean to be negative, but have you ever asked yourself why projects fail? I’m sure you can come up with a great long list. Today I’d like to address just one – trying to do too much, also known as having the wrong scope.

You must have come across projects which you feel would have succeeded if only they had set their sights a little lower – and stuck with that. I’m not just talking about “Scope Creep” where the project grows during its course, but I’m including the projects where the scope was too big from the beginning.

Realism versus Optimism

Optimism is a good thing. If we don’t believe we are going to succeed, we are unlikely to start a project. If we don’t believe we can succeed, we are not going to try and we almost guarantee failure.

On the other hand, if we commit to a project which will require all the resources we have, and then something else comes up, then again we are not going to succeed.

The scope of a project needs to be realistic. It needs to recognise that the objectives of the project need to be compatible with the constraints and the environment in which it operates. A project which has to deal with outside events is likely to be less productive.

One of the keys to effective project management is for the sponsors, management and workers to agree what they want to achieve – and then stick to the plan!

Getting Scope right in the first place

Agreeing the scope of a project is one of those areas where technical skills and so-called “soft skills” are required. You may find what you are doing being influenced by politics and things outside your control.

There are tools you can use to help you to get and to document agreement. Aim to get the different parties to agree what is “in scope” and what is “out of scope”.

The Agile project management methods emphasise prioritisation and create opportunities to adjust the scope of each iteration. There is less need to get it absolutely right first time.

Tools for getting scope right

I recommend holding workshops where the different stakeholders can agree what the project scope. Within these workshops, I use a technique to help the participants agree and document the project scope. The technique is simple and I have created a short course so you can learn. Go and have a look now.

Prioritisation: Are you doing the right things?

Priorities over diary page — Prioritisation means knowing what you are going to do.

I know you’re terribly busy, but take a moment to ask “am I doing the right things?” If someone shouted

“Stop what you are doing!”

right now, would you look back at what you had created and be satisfied, or would you wish you had put the effort into something different?

Get your priorities right

Sooner or later every project comes to an end. Projects can end for many reasons:

All the work has been completed
We’ve run out of time, or
We’ve run out of money (budget)
Someone in charge says “I’ve changed my mind. Stop!”

Knowing what the priorities are as an individual and as a project at each stage is extremely powerful. It means that you know where to put your effort, you know what to do next, when you finish a task, or a task become “blocked” and it means that you know what you are _not_ going to do (at least for the time being).

Prioritisation: How should you decide your priorities?

You can do it on the basis of maximising benefit or minimising risk or cost or any other criteria you decide. Those in authority (which might or might not include you) should discuss the priorities (that includes having a good argument about them) for phase of the project you are working on, agree what the priorities are and then stick to that plan.

One of the strengths of the various “Agile” project management methods is the emphasis they put on agreeing the objectives or priorities of a time-box, iteration or sprint. Personally, I like to use MoSCoW for this, where:

M= Must have. There should only be one or two “Must haves” for each time-box.
S= Should have. There can be several “Should haves”
C=Could have. There can be several “Could haves”, and finally
W=Won’t have (this time around).

This approach concentrates on the “Must Haves” and only starts on the “Should Haves” when they have been completed. If you get it right, you run out of time or budget ideally somewhere in the Could haves (if you do well) or in the Should haves (if you make less progress than you hope).

Make sure that when someone calls “stop!” you (and everyone else) thinks they have received good value for your efforts.

Slack: Add a little contingency to your project

Meshed gears need "slack" — Meshed Gears need appropriate clearance or “slack”

“Slack” is a central idea of The Church of the Sub-Genius. They don’t define “Slack”, but they imply say that J.R “Bob” Dobbs is the embodiment of it.

I’m careful to respect the beliefs of others, even when I’m not sure they expect to be taken seriously, but you can find useful ideas in the strangest of places!

One way of looking at slack, is as time which is not allocated to productive activity. If we use this definition:

How can “slack” possibly make a project more successful?

Why we all need a little Slack

One reason for including a little slack is to account for uncertainty in estimates. If we schedule every task exactly the amount of time we think it will take and no more, and anything runs over time, then our completion date will start to slip.
Another reason for allowing a little slack is to allow people to review what they are doing (to “Think”, to use a once popular slogan). That way they can identify ways of doing their work more effectively and possibly improving their own productivity.
Finally, machines (like the gears in the illustration) which are operated without adequate clearances tend to require extra energy to drive them and break down more frequently. On the other hand, if clearances are too great, then gears become noisy and inefficient.

How do we know that we have the right amount of “slack”?

I am not arguing for inflating all estimates. Inflated estimates simply increase costs. Too much slack is as bad as too little. The signs that we have the wrong amount of “slack” or contingency are:

Too little slack: There is always difficulty completing any task on schedule. Even slight problems cause significant delays. Of course, there may be other reasons.
Too much slack: Everything is completed easily on schedule – in fact “the job is expanding to match the time available”.

How do we add “slack” to our project plan?

Slack can be added to individual tasks or to the project as a whole. It can also be added as recognised lower priority activities which we can decide to sacrifice if we need to. There are arguments for and against all approaches. Whatever approach you take, you should try and track how you are using any contingency you have added to your plan.

Is there the appropriate amount of “slack” in your project?

Look at whatever you are working on.

If the estimates are right “on average”, do you have enough “slack” to allow for the inconsistencies?
Do you have enough “thinking time”?