Review: How was it for you?

Review - How was it for you?
Review – How was it for you?

What is your opinion of someone who keeps on making the same mistake? I expect it is probably not very high. Making mistakes is inevitable, but we should learn from them. Having a “review” is one way we can do this.

Having a review means taking the time to look at what we did and how we did it. We can learn from what we did, and do better the next time.

Review: When, How, What?

Hold your review when something is complete and when it is still fresh in people’s minds.

I prefer “light weight”, “low ceremony” activities. Doing our review that way means we can do it quickly and cheaply.  The simplest way is to ask the people involved – “How was it for you?”

Keep it simple. Make the product of your review a few things you plan to improve the next time, and then put those changes into effect.

The idea of reviewing what you have done fits naturally into the iterative structure of Agile projects, but it can also be applied with Waterfall.

Use reviews to improve your productivity:

A review is intended to help us to: “Do it better next time!” The effort which goes into the review must be repaid by the improvements it causes.

  • Remember to include the different groups involved. If we are talking about a specification or requirements document, include: Business Users, Developers and Testers. The objective is not to find “what went wrong?” but to find a way to “do it better!”
  • Keep it simple. Make the product of your review a few things you plan to improve the next time. Make sure your review has some visible effect. People like to feel they have influenced how things are working. On the other hand, people do not like to be ignored. It is demotivating.

Some of the suggestions from different parties may be contradictory. For example: Some people may want more detail and others want to spend less time producing documentation. This is a challenge to your imagination, creativity and skill at negotiation.

What is the next step?

Adding reviews like this to your process is something you can do in a stealthy way. Start by identifying a work-product which is coming up for completion.

  • Who would you involve in your review?
  • When and how are you going to get hold of them?
  • What specific questions will you ask them?
  • How long will you allow yourself to manage the review so you can incorporate its findings into the next suitable activity?

Good luck! Have fun and tell me how you get on with your reviews.

Re-planning: Path to Success or Mark of Failure?

Project Gantt Chart
Project Gantt Chart

When did you last revise your project plan? Did it make you feel you had failed, or did you feel it was an essential step on the path to success?

I would argue that re-planning is a necessary part of projects.

Re-planning: Just part of project life

I have met people who felt that “re-planning” or revising a project plan was an admission of defeat. They feel they should have anticipated everything in advance and built it into the original plan. I think they are being unnecessarily hard on themselves.

Unless you have complete foreknowledge about everything in and around your project, then some degree of re-planning is inevitable.

Re-planning to suit your project

To oversimplify things a little, there are two kinds of project, “Waterfall” and “Agile”.

  • With Waterfall, you can really only plan one phase at a time in any detail. That means that one of the concluding outputs from each phase is the detailed plan for the next phase. This means that you have to revisit the plan with each new phase. It’s an essential part of the method.
  • With Agile, you plan each iteration or sprint as it comes up. Again, this means planning again and again. The plans may be smaller, because the steps are smaller but they are still there.

In both cases the smaller plans fit within a larger, coarser grained project plan.

How up to date is your plan?

One of the advantages of re-planning or revising your plan is that it allows you to take what you have learned from your project into account. It means that the projections in you plan are more likely to be accurate and therefore you can take action to try to achieve them. Having an out of date plan which contains unachievable completion dates is demotivating. Bring your plan up to date and then manage to the up-to-date plan!

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

Project Check-Point
Project Check-Point

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?

Bright Idea!
Bright Idea!

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.