Gary M. Nelson's Blog, page 5
August 8, 2012
Built to Last: Forget Waterfall, Forget Agile - Let's Talk Tectonic Project Methodologies
[Also available as a podcast]
Have you ever managed a really big project? I am certain that many of you have managed some very large projects. But how big is that, exactly? As big as the pyramids? Well, maybe some of you have. But there are some projects that make even those pale in comparison.
As a matter of fact, I am currently sitting in the middle of one of the world's largest Projects. No, it was not my project - not by a long shot. We don't actually have the email or mobile number for the project manager responsible - but you can clearly see the results.
I am sitting here typing away in Hamilton - roughly in the middle of the North Island of New Zealand.
No, Hamilton is bigger than a pyramid, but it is not the project either. It is a nice place to live, and a medium sized city for New Zealand - actually the largest inland city as the main ones are along one coast or another.
The project of which I am speaking is the whole of the North Island itself. The island is 113,729 square kilometres (43,911 sq mi) in area, making it the world's 14th-largest island.
Ok, ok, you say - what's the point, and how is this a project?
I suggest this is a project because it is almost entirely volcanic in origin. Just like Hawaii or any of the smaller pacific islands - but on a much, much larger scale - both geographically and the project timeline.
I guess we should really call it a Program, because it is so large. Ok then, it's a very large program - with each of the volcanoes an individual project. 27 major volcanoes in the Taupo Volcanic zone itself, with another 15 or so scattered in the North Island - well, much more than that because the Auckland Volcanic Field features more than 60 cones. After a while, you lose count of the smaller volcanoes.
Then there is the South Island - a very different kind of project and island.
So - let's translate this to Project Management terms - and build ourselves an island or two.
Making an IslandWhy the sudden interest in geology? August 6, 2012, 23:50 - Mt Tongariro erupted for the first time since 1897. Mt Tongariro is a large volcano just to the south of Lake Taupo. It has several nearby sister volcanoes, Mt Ngarahoe, which last erupted in 1977 and is technically a vent on Mt Tongariro, and Mt Ruapehu, an impressive volcano with several major ski fields which last erupted in 1995-1996. And of course, Lake Taupo itself (616 square km / 238 square miles) is in the crater of New Zealand's largest volcano.
Mt Ruapehu and Ngarahoe (right), Taupo Volcanic Zone
Growing an island by volcano is a much different activity than slamming tectonic plates together and uplifting a new mountain range - a process called thrust faulting, where the shock wave of the plate collision forces huge masses of rock to crack and slide up over its neighbour. This is how the South Island, the Rockies and all major mountain ranges formed.
The other way - one might even say a more elegant way - to grow an island is slowly, progressively, from the bottom up like the North Island. Layer upon layer, the volcanic cones rise from magma vents in the ocean floor until they break through the surface of the water - a noisy birth with lots of steam and splashing. Most of the Pacific Islands formed this way, and the peak is just the tip of a very tall volcanic cone rising from the sea floor. Some quit shortly after they broke through the water - forming a lot of the smaller islands, while others continued to grow and form mountains and valleys in between.
Comparing Tectonic Project MethodologiesOk, so we have two main methods to choose from to build your island and raise it up above the waterline, or increase its height.
Thrust Fault (convergent plate movement)Volcanic (convergent or divergent plate movement)Both processes occur due to changes at plate boundaries, and you may even have volcanic activity around the edges of a thrust fault, depending on any weak points (hot spots) created along the underlying plate.
But enough geology - how does this apply to projects? Both have the same eventual goal - to create an island where once there was water. Let's look at the differences in approach - and the lessons we can learn when applied to our projects.
Thrust Fault ProjectsSome projects have a lot of things thrust together by force to produce a project outcome - often with major clashes and collisions between stakeholders and the project team as well. And although the results can be breathtaking when you look at it later, it is certainly disruptive while the building-up part is going on. Car wrecks are sudden, spectacular and breathtaking too - just not very healthy for the stakeholders.
The main feature about this methodology is the use of sudden change to complete the project after a long quiet buildup. With little or no warning, there is a flurry of activity, a lot of energy expended, and suddenly it is over and things will never be the same again.
One of the problems with this approach from a people perspective is that sudden, unexpected change tends to cause resentment and feelings of loss to those affected. This may be the users of the old system, or a person whose house was flattened by the Richter 9.5 triggered by the nearby hill's ambition to suddenly become a mountain. In both cases, you have ripped out the foundations from underneath people with no warning or preparation - in other words, there was no Change Management Plan . Put simply, there was not a lot of communication about what was coming, period.
One minute, you and all your fishy buddies are swimming away close to the shoreline, and then - BAM!- you are high and dry and upwardly mobile. No change management plan for you - learn to walk and breathe air, or die. Not everyone survives this type of project.
In real life, an event like this results in a major earthquake - and it is usually not the last. There is almost always an adjustment period, as things settle into place - accompanied by a rash of smaller earthquakes over time. Expect the same things on your Thrust Fault projects - when you suddenly change or impose things on your users, there will be a lot of adjusting, support and probably apologizing to do before they settle in to the new way of things.
Project Change Requests in this type of project are rarely uneventful.
And like the vertical adjustment to Mt Cook a couple years back, where a huge chunk of rock slid off the peak down into the valley, not everyone will want to stay on after the thrust fault event, but they might not leave right away. Just don't be surprised when they do leave.
Of course, not all Thrust-Fault projects are bad news. If you are launching a new product or a rocket to the stars, you will necessarily have your major event at the end. There will be a lot riding on the outcome, and a lot of internal activity leading up to it - but it is not as visible as the actual public launch.
Volcanic ProjectsVolcanoes get a bad rap. Compared to the energies and destruction caused by raising a thrust-fault mountain range, volcanoes are positively gentle. When they are first forming, you have plenty of warning that they are coming - gas venting, steam, warming of the water. Once they clear the water, they even provide you with night-lights to stay clear as the red-hot magma flows down the mountain side. If it thinks you are getting to close for your own safety, it may blow off some steam or ash. They are playful too - they may toss you a few pyroclastic boulders. (I don't recommend you do the "catching" part though). Sometimes you even get a free fireworks display.
Sure, they can cause destruction and changes to the terrain, but aside from ash clouds there are limited effects far from the volcano. Lava flows downhill, boulders can only be tossed so far. I am not downplaying ash clouds though - they can be very disruptive to the areas coated with ash - nearby and far afield, and they are a threat to aircraft. However this is a matter of perspective. None of us have seen a mountain range suddenly thrust out out of the earth beneath you. Volcanic eruptions are much more common in comparison. It is unlikely you would survive a mountain-building thrust fault event near you - you have a much higher chance of survival being near a volcano, as bad as it may seem.
The main feature about this methodology that makes it preferable on most projects is that while you are building your volcano, it is a gradual process. You have plenty of time to communicate with those affected and utilize a Change Management Plan as you build up towards the project goals, layer by layer. Sure, there will be some excitement and fireworks, but most of the growth in your project will be like the layering of magma as the volcano grows taller. While magma is flowing, the Volcano is actually relatively happy - there is a steady release of pressure without excessive build-ups. It is only when you run into obstacles and blockages that you have a danger of outbursts or violent eruptions. But again - you have the element of time. It takes many years to grow a volcano, so even though there seems to be bursts of short-term activity, the overall progress is relatively steady.
The one trick with volcanoes, of course, is the Project Change Requests. With a Thrust Fault project, you know to expect a flurry of these after the main event, and then things will tail off. With the Volcanic Project, things may seem to be quiet for a long period and then you may have an unexpected eruption of post-build activity.
Not a problem, really - unless you decided to build your house on the side of the volcano because of the nice view.
SummarySo what kind of project are you on? Thrust-Fault or Volcano? The needs of your project will generally dictate which approach is best.
If your project outcome is necessarily a sudden cut-over or launch type event, you might need to use Thrust-Fault. (Just do as much as you can on the communication side of things)If your project outcome affects a lot of people, it is usually best to use the Volcano approach when you can - build up slowly, and employ your Change Management Plan liberally.
The key is to keep an eye on how your project is turning out - if you planned for a Volcano, watch that you don't end up with a Thrust-Fault because you stopped communicating. It makes for a strangely shaped deliverable.
Good luck with your projects, and if you get a chance, come on "down under" to visit New Zealand. You will see an amazing variety of geology and scenery if you do!
Gary Nelson, PMP
Gazza Consulting Services
Have you ever managed a really big project? I am certain that many of you have managed some very large projects. But how big is that, exactly? As big as the pyramids? Well, maybe some of you have. But there are some projects that make even those pale in comparison.
As a matter of fact, I am currently sitting in the middle of one of the world's largest Projects. No, it was not my project - not by a long shot. We don't actually have the email or mobile number for the project manager responsible - but you can clearly see the results.
I am sitting here typing away in Hamilton - roughly in the middle of the North Island of New Zealand.
No, Hamilton is bigger than a pyramid, but it is not the project either. It is a nice place to live, and a medium sized city for New Zealand - actually the largest inland city as the main ones are along one coast or another.
The project of which I am speaking is the whole of the North Island itself. The island is 113,729 square kilometres (43,911 sq mi) in area, making it the world's 14th-largest island.
Ok, ok, you say - what's the point, and how is this a project?
I suggest this is a project because it is almost entirely volcanic in origin. Just like Hawaii or any of the smaller pacific islands - but on a much, much larger scale - both geographically and the project timeline.
I guess we should really call it a Program, because it is so large. Ok then, it's a very large program - with each of the volcanoes an individual project. 27 major volcanoes in the Taupo Volcanic zone itself, with another 15 or so scattered in the North Island - well, much more than that because the Auckland Volcanic Field features more than 60 cones. After a while, you lose count of the smaller volcanoes.
Then there is the South Island - a very different kind of project and island.
So - let's translate this to Project Management terms - and build ourselves an island or two.
Making an IslandWhy the sudden interest in geology? August 6, 2012, 23:50 - Mt Tongariro erupted for the first time since 1897. Mt Tongariro is a large volcano just to the south of Lake Taupo. It has several nearby sister volcanoes, Mt Ngarahoe, which last erupted in 1977 and is technically a vent on Mt Tongariro, and Mt Ruapehu, an impressive volcano with several major ski fields which last erupted in 1995-1996. And of course, Lake Taupo itself (616 square km / 238 square miles) is in the crater of New Zealand's largest volcano.
Mt Ruapehu and Ngarahoe (right), Taupo Volcanic ZoneGrowing an island by volcano is a much different activity than slamming tectonic plates together and uplifting a new mountain range - a process called thrust faulting, where the shock wave of the plate collision forces huge masses of rock to crack and slide up over its neighbour. This is how the South Island, the Rockies and all major mountain ranges formed.
The other way - one might even say a more elegant way - to grow an island is slowly, progressively, from the bottom up like the North Island. Layer upon layer, the volcanic cones rise from magma vents in the ocean floor until they break through the surface of the water - a noisy birth with lots of steam and splashing. Most of the Pacific Islands formed this way, and the peak is just the tip of a very tall volcanic cone rising from the sea floor. Some quit shortly after they broke through the water - forming a lot of the smaller islands, while others continued to grow and form mountains and valleys in between.
Comparing Tectonic Project MethodologiesOk, so we have two main methods to choose from to build your island and raise it up above the waterline, or increase its height.
Thrust Fault (convergent plate movement)Volcanic (convergent or divergent plate movement)Both processes occur due to changes at plate boundaries, and you may even have volcanic activity around the edges of a thrust fault, depending on any weak points (hot spots) created along the underlying plate.
But enough geology - how does this apply to projects? Both have the same eventual goal - to create an island where once there was water. Let's look at the differences in approach - and the lessons we can learn when applied to our projects.
Thrust Fault ProjectsSome projects have a lot of things thrust together by force to produce a project outcome - often with major clashes and collisions between stakeholders and the project team as well. And although the results can be breathtaking when you look at it later, it is certainly disruptive while the building-up part is going on. Car wrecks are sudden, spectacular and breathtaking too - just not very healthy for the stakeholders.
The main feature about this methodology is the use of sudden change to complete the project after a long quiet buildup. With little or no warning, there is a flurry of activity, a lot of energy expended, and suddenly it is over and things will never be the same again.
One of the problems with this approach from a people perspective is that sudden, unexpected change tends to cause resentment and feelings of loss to those affected. This may be the users of the old system, or a person whose house was flattened by the Richter 9.5 triggered by the nearby hill's ambition to suddenly become a mountain. In both cases, you have ripped out the foundations from underneath people with no warning or preparation - in other words, there was no Change Management Plan . Put simply, there was not a lot of communication about what was coming, period.
One minute, you and all your fishy buddies are swimming away close to the shoreline, and then - BAM!- you are high and dry and upwardly mobile. No change management plan for you - learn to walk and breathe air, or die. Not everyone survives this type of project.
In real life, an event like this results in a major earthquake - and it is usually not the last. There is almost always an adjustment period, as things settle into place - accompanied by a rash of smaller earthquakes over time. Expect the same things on your Thrust Fault projects - when you suddenly change or impose things on your users, there will be a lot of adjusting, support and probably apologizing to do before they settle in to the new way of things.
Project Change Requests in this type of project are rarely uneventful.
And like the vertical adjustment to Mt Cook a couple years back, where a huge chunk of rock slid off the peak down into the valley, not everyone will want to stay on after the thrust fault event, but they might not leave right away. Just don't be surprised when they do leave.
Of course, not all Thrust-Fault projects are bad news. If you are launching a new product or a rocket to the stars, you will necessarily have your major event at the end. There will be a lot riding on the outcome, and a lot of internal activity leading up to it - but it is not as visible as the actual public launch.
Volcanic ProjectsVolcanoes get a bad rap. Compared to the energies and destruction caused by raising a thrust-fault mountain range, volcanoes are positively gentle. When they are first forming, you have plenty of warning that they are coming - gas venting, steam, warming of the water. Once they clear the water, they even provide you with night-lights to stay clear as the red-hot magma flows down the mountain side. If it thinks you are getting to close for your own safety, it may blow off some steam or ash. They are playful too - they may toss you a few pyroclastic boulders. (I don't recommend you do the "catching" part though). Sometimes you even get a free fireworks display.
Sure, they can cause destruction and changes to the terrain, but aside from ash clouds there are limited effects far from the volcano. Lava flows downhill, boulders can only be tossed so far. I am not downplaying ash clouds though - they can be very disruptive to the areas coated with ash - nearby and far afield, and they are a threat to aircraft. However this is a matter of perspective. None of us have seen a mountain range suddenly thrust out out of the earth beneath you. Volcanic eruptions are much more common in comparison. It is unlikely you would survive a mountain-building thrust fault event near you - you have a much higher chance of survival being near a volcano, as bad as it may seem.
The main feature about this methodology that makes it preferable on most projects is that while you are building your volcano, it is a gradual process. You have plenty of time to communicate with those affected and utilize a Change Management Plan as you build up towards the project goals, layer by layer. Sure, there will be some excitement and fireworks, but most of the growth in your project will be like the layering of magma as the volcano grows taller. While magma is flowing, the Volcano is actually relatively happy - there is a steady release of pressure without excessive build-ups. It is only when you run into obstacles and blockages that you have a danger of outbursts or violent eruptions. But again - you have the element of time. It takes many years to grow a volcano, so even though there seems to be bursts of short-term activity, the overall progress is relatively steady.
The one trick with volcanoes, of course, is the Project Change Requests. With a Thrust Fault project, you know to expect a flurry of these after the main event, and then things will tail off. With the Volcanic Project, things may seem to be quiet for a long period and then you may have an unexpected eruption of post-build activity.
Not a problem, really - unless you decided to build your house on the side of the volcano because of the nice view.
SummarySo what kind of project are you on? Thrust-Fault or Volcano? The needs of your project will generally dictate which approach is best.
If your project outcome is necessarily a sudden cut-over or launch type event, you might need to use Thrust-Fault. (Just do as much as you can on the communication side of things)If your project outcome affects a lot of people, it is usually best to use the Volcano approach when you can - build up slowly, and employ your Change Management Plan liberally.
The key is to keep an eye on how your project is turning out - if you planned for a Volcano, watch that you don't end up with a Thrust-Fault because you stopped communicating. It makes for a strangely shaped deliverable.
Good luck with your projects, and if you get a chance, come on "down under" to visit New Zealand. You will see an amazing variety of geology and scenery if you do!
Gary Nelson, PMP
Gazza Consulting Services
July 23, 2012
Lather, Rinse, Repeat - Why We Need to Re-Plan Projects
[Also available as a podcast]
Lather, Rinse, Repeat.
You will find these instructions (or some variation) on most shampoo bottles. Why include these instructions in the first place? Does it mean that the shampoo is actually not that good and you need a double dose? Or, could it possibly be they think you are extra dirty and need the extra round of cleaning (which might be kind of insulting)?
Actually, it is neither of those reasons.
The shampoo is not necessarily faulty, nor are you likely that gamey. The reason they put those instructions on the bottle is that they know the secret of doing a job effectively. The first round cleans most of the pollution, grease and dirt out of your hair - the next round does a final pass to make sure your hair is actually clean, and not just "less dirty".
Other two-part solutions abound - floss before you brush your teeth; your teeth will be healthier if you loosen up the stuff that is stuck between your teeth and then brush and rinse it away.
Painting a room? Don't ever believe the "one coat" label on the can or the brush. Every good painter (DIY or professional) knows that you need (at least) two coats for a good finish. One time round is simply not enough, unless you are freshening up the room with the same exact colour within a couple years. But if you change colours, you will need two coats, and possibly a primer/sealer before that to help hide the old colour. And the bigger the colour change between old and new, the more coats you are likely to need to cover it.
Not surprisingly, the same approach applies to Project Planning, however we are not limited to just a second pass; depending on the length of your project you may end up doing multiple rounds of re-planning to make sure that things are going to get done effectively.
Because - as every Project Manager knows, your project plan becomes obsolete the moment you save it or print it out.
Your Project Plan Has a Best Before DateEvery project plan has a best before date. What that date is depends on a number of factors, including the number of "moving parts", work streams, dependencies and the overall complexity of your project. Even "set in stone" dates can change, for example you have had training booked in from several months ago, and then a tornado flattens the training center in the middle of the night. One way or another, you are going to have to adjust your plans - delay or relocate.
As Project Managers, we are actually tweaking the direction every day - usually small changes, adjustments, a day or two here, a resource there. Gradually, bit by bit - the reality of your project wanders off away from the path you originally set out on. You might even need to continue on the path you are on right now - but for everyone involved, it is important that you do so consciously, as part of the plan. Or perhaps you need to get back on track, regroup, assess and re-chart your path back to the destination.
When your project is starting to look substantially different from the plan, or every month or so, whichever comes first, you should be reviewing and adjusting the overall plan.
Because after all - we don't actually have an auto-pilot.
How Autopilot WorksYou may not know this, but most commercial aircraft can take off, fly and land by themselves. We are all familiar with the middle part - the flying part, but they can actually do the rest as well. They rarely use it for takeoff and landing, but they do test it from time to time when the conditions are good, with a human hand ready to take over at a moment's notice. Fortunately for us, projects are so complex and conditions so variable that no-one has yet invented an "Automatic Project Manager" to initiate and complete projects.
What is worth looking at, however, is how autopilot actually works. Every moment of your flight, you are flying slightly off-course. The wind nudges you a little up or down, left or right. If your plane kept flying in that adjusted direction, you would end up hundreds of miles or more from your destination. Fortunately, the auto-pilot knows where you came from, where you are now, and where you are supposed to end up. So every so often, at least every few minutes, the plane adjusts the rudder or ailerons to put you back on track.
Your project does not have an auto-pilot. Which is fortunate, as you would then not have a job much longer. Fortunately, they have you - the Experienced Project Manager to perform that function.
As long as you actually do the job of checking your direction and adjusting course back to the destination, that is. If you simply set your plan and then execute your project without checking that you are still going in the right direction, you will easily end up hundreds of miles from where you had planned to in the first place. Or, you might get "stuck in a spin" and fail to make forward progress, and spiral down, down, down until you crash.
So you should plan to make regular course adjustments - beyond the minor day to day tweaks. You need to periodically check all of your instruments, see where you are now, and where it looks like you are going, and update your project plan. There is even a Project Management word for what you do when you take stock, verify where you are and update the plan and direction. It is called baselining . It's important enough that they invented a word for it, so we might as well use it, right?
Another reason we need to re-look at the plan on a regular basis is that none of us can see very well beyond the nearby stuff - at least not the detail. And most of the time you can imagine, but not actually see the far-off destination, which may still be well over the horizon. So let's start with a Project Eye Exam to see if that can help.
20/20 Is Only Good For a Short DistanceIn my pre-teens I needed to get glasses. I had them for many, many years until I braved laser vision treatment. Best decision I ever made regarding my eyes - but anyway, the point here is that I needed corrective lenses (and eventually a permanent treatment when glasses could only do so much and things were still a bit fuzzy) to see as well as someone with "normal" vision.
But the thing with "normal" vision, or 20/20, is that it is still limited.
20/20 simply means that you can see at 20 feet what a "normal vision person" should be able to see at 20 feet - usually measured by being able to read tiny letters.
And really - 20 feet is not that far away. You can throw much farther than that.
At 25 to 30 feet, well, almost nobody can read the bottom line. And although those mountains are certainly pretty in the distance, you can't see the ski chalet or the sunbather on the upper balcony, or the title of the book they are reading - let alone the words on the page, which are the same size as the bottom line on the chart 20 feet away from you.
Our "detail" vision is limited to the things near to us. So you go out and buy a telescope - and suddenly you can see the chalet. Zoom in, and you can see the sunbather. Up the magnification and you can see the book title; notch it up further and you can read the page they are on (if only you hold the telescope steady enough and if they would just hold their hand still - it is getting to a good part!). However, you can no longer see the mountain. Perspective changes and limits what we see at one time. (You can't see the forest for the individual trees!)
The same rule applies to projects - although we generally do not speak in distance, but in time and deliverables.
The book that sunbather was reading looks really good - I think I'll go over and check it out.
When we draw up our project plans, we can define and be reasonably able to execute tasks on the schedule that are defined in days or even hours - but the further out you go, the details become more fuzzy. And so far, there is no Lasik or project telescope that has been invented that can help with resolving all of those far-off project details.
However, some things we can define (barring major risk events) with great precision into the far future - these are the anchor dates, deadlines, due dates and when you have specific booked activities. But for the rest, things tend to be more fluid and variable. And we need to keep these variable things on track if we ever hope to actually meet those deadlines, due dates and be able to deliver training course XYZ on June 1, two years from now.
It is the variability of those tasks in progress that require you to keep checking and correcting your course - and adding more and more detail.
This is a longer walk than I expected - the mountain looked so close! Well, I am almost there now so I better keep going...but I better grab some snacks along the way and work my way around that wet patch up ahead.
You can plan for what you can "see" - and have a rough plan for the next stages of the project journey. You can map things out in great detail to make it to the closest hill, but then you need to assess the lay of the land, navigate around the swamp you did not know was on the other side, and chart your next leg in detail to the next major point or milestone. It is in this way that we navigate through the world and through your projects, and make it to the destination on the other side.
One rule of thumb I have used in my project planning is this:
- Over the next 30 days, we can define and schedule tasks at the resolution of a day.
- Between 30-60 days, the resolution is around 2 days, give or take.
- Between 60-120 days, the resolution is at one week.
- Between 120-180 days, the resolution is at 2 weeks or more.
- Over 180 days, the resolution is at 1 month or more, and will become a summary task with more detail to be added as we get closer.
(Note that this is for duration and scheduling of assignments, not necessarily effort, though we will understand that better the closer we are to it as well).
Every time we reviewed the project plan and updated it (every month or two, if things were going relatively smoothly, or more often if not), we would review what had been accomplished so far, and then look out over the coming months and break tasks down into finer resolution and detail roughly following the model above. In this way, we had a rolling project plan with progressively more and more detail as we went along - but still a high level overview as we looked out farther into the future.
At every stage, the mountains get closer, but they are still just a little ways further off, until you finally reach your destination at the ski chalet.
The sunbather is long gone, but fortunately they left the book behind. You are also looking to rent some ski gear, because, well hey - it was a long walk and now it is early winter. But the upside is, you are here in time for ski season - and the powder is fresh, awaiting your first run. And when you finish your last run of the day, you can sit by the fire and read that book you have been looking forward to for so long.
SummaryThis article has taken us on quite a journey - from the label of a shampoo bottle to flying across the country, stopping in for an eye exam and walking long-distance to a ski resort. A mix of metaphors, perhaps, but each had a part to play in the overall lesson.
You need to be aware of your perspective when you are developing your project plan - you cannot see very many details past a fairly short period of time (weeks, or a few months). Your long-distance detail vision is not as good as you think it is. You need to Review where you are and add detail for the next group of tasks as you go.You need to make course corrections along the way. You need to Re-Plan to keep things on track, if you start to drift off course.Finally, you need to do it more than once. Perhaps not as often as an airplane, which is every few minutes - but you do need to Repeat it regularly.
So the lesson can be summarized as: "Plan your projects, and on a regular basis, Review, Re-Plan, Repeat".
Cheers and good luck with your projects. Until they develop a Project Auto-Pilot (and I hope they never do), we will just have to keep everything on track ourselves.
Gary Nelson, PMP
Gazza Consulting Services
Lather, Rinse, Repeat.
You will find these instructions (or some variation) on most shampoo bottles. Why include these instructions in the first place? Does it mean that the shampoo is actually not that good and you need a double dose? Or, could it possibly be they think you are extra dirty and need the extra round of cleaning (which might be kind of insulting)?
Actually, it is neither of those reasons.
The shampoo is not necessarily faulty, nor are you likely that gamey. The reason they put those instructions on the bottle is that they know the secret of doing a job effectively. The first round cleans most of the pollution, grease and dirt out of your hair - the next round does a final pass to make sure your hair is actually clean, and not just "less dirty".
Other two-part solutions abound - floss before you brush your teeth; your teeth will be healthier if you loosen up the stuff that is stuck between your teeth and then brush and rinse it away.
Painting a room? Don't ever believe the "one coat" label on the can or the brush. Every good painter (DIY or professional) knows that you need (at least) two coats for a good finish. One time round is simply not enough, unless you are freshening up the room with the same exact colour within a couple years. But if you change colours, you will need two coats, and possibly a primer/sealer before that to help hide the old colour. And the bigger the colour change between old and new, the more coats you are likely to need to cover it.
Not surprisingly, the same approach applies to Project Planning, however we are not limited to just a second pass; depending on the length of your project you may end up doing multiple rounds of re-planning to make sure that things are going to get done effectively.
Because - as every Project Manager knows, your project plan becomes obsolete the moment you save it or print it out.
Your Project Plan Has a Best Before DateEvery project plan has a best before date. What that date is depends on a number of factors, including the number of "moving parts", work streams, dependencies and the overall complexity of your project. Even "set in stone" dates can change, for example you have had training booked in from several months ago, and then a tornado flattens the training center in the middle of the night. One way or another, you are going to have to adjust your plans - delay or relocate.
As Project Managers, we are actually tweaking the direction every day - usually small changes, adjustments, a day or two here, a resource there. Gradually, bit by bit - the reality of your project wanders off away from the path you originally set out on. You might even need to continue on the path you are on right now - but for everyone involved, it is important that you do so consciously, as part of the plan. Or perhaps you need to get back on track, regroup, assess and re-chart your path back to the destination.
When your project is starting to look substantially different from the plan, or every month or so, whichever comes first, you should be reviewing and adjusting the overall plan.
Because after all - we don't actually have an auto-pilot.
How Autopilot WorksYou may not know this, but most commercial aircraft can take off, fly and land by themselves. We are all familiar with the middle part - the flying part, but they can actually do the rest as well. They rarely use it for takeoff and landing, but they do test it from time to time when the conditions are good, with a human hand ready to take over at a moment's notice. Fortunately for us, projects are so complex and conditions so variable that no-one has yet invented an "Automatic Project Manager" to initiate and complete projects.
What is worth looking at, however, is how autopilot actually works. Every moment of your flight, you are flying slightly off-course. The wind nudges you a little up or down, left or right. If your plane kept flying in that adjusted direction, you would end up hundreds of miles or more from your destination. Fortunately, the auto-pilot knows where you came from, where you are now, and where you are supposed to end up. So every so often, at least every few minutes, the plane adjusts the rudder or ailerons to put you back on track.
Your project does not have an auto-pilot. Which is fortunate, as you would then not have a job much longer. Fortunately, they have you - the Experienced Project Manager to perform that function.
As long as you actually do the job of checking your direction and adjusting course back to the destination, that is. If you simply set your plan and then execute your project without checking that you are still going in the right direction, you will easily end up hundreds of miles from where you had planned to in the first place. Or, you might get "stuck in a spin" and fail to make forward progress, and spiral down, down, down until you crash.
So you should plan to make regular course adjustments - beyond the minor day to day tweaks. You need to periodically check all of your instruments, see where you are now, and where it looks like you are going, and update your project plan. There is even a Project Management word for what you do when you take stock, verify where you are and update the plan and direction. It is called baselining . It's important enough that they invented a word for it, so we might as well use it, right?
Another reason we need to re-look at the plan on a regular basis is that none of us can see very well beyond the nearby stuff - at least not the detail. And most of the time you can imagine, but not actually see the far-off destination, which may still be well over the horizon. So let's start with a Project Eye Exam to see if that can help.
20/20 Is Only Good For a Short DistanceIn my pre-teens I needed to get glasses. I had them for many, many years until I braved laser vision treatment. Best decision I ever made regarding my eyes - but anyway, the point here is that I needed corrective lenses (and eventually a permanent treatment when glasses could only do so much and things were still a bit fuzzy) to see as well as someone with "normal" vision.
But the thing with "normal" vision, or 20/20, is that it is still limited.
20/20 simply means that you can see at 20 feet what a "normal vision person" should be able to see at 20 feet - usually measured by being able to read tiny letters.
And really - 20 feet is not that far away. You can throw much farther than that.
At 25 to 30 feet, well, almost nobody can read the bottom line. And although those mountains are certainly pretty in the distance, you can't see the ski chalet or the sunbather on the upper balcony, or the title of the book they are reading - let alone the words on the page, which are the same size as the bottom line on the chart 20 feet away from you.
Our "detail" vision is limited to the things near to us. So you go out and buy a telescope - and suddenly you can see the chalet. Zoom in, and you can see the sunbather. Up the magnification and you can see the book title; notch it up further and you can read the page they are on (if only you hold the telescope steady enough and if they would just hold their hand still - it is getting to a good part!). However, you can no longer see the mountain. Perspective changes and limits what we see at one time. (You can't see the forest for the individual trees!)
The same rule applies to projects - although we generally do not speak in distance, but in time and deliverables.
The book that sunbather was reading looks really good - I think I'll go over and check it out.
When we draw up our project plans, we can define and be reasonably able to execute tasks on the schedule that are defined in days or even hours - but the further out you go, the details become more fuzzy. And so far, there is no Lasik or project telescope that has been invented that can help with resolving all of those far-off project details.
However, some things we can define (barring major risk events) with great precision into the far future - these are the anchor dates, deadlines, due dates and when you have specific booked activities. But for the rest, things tend to be more fluid and variable. And we need to keep these variable things on track if we ever hope to actually meet those deadlines, due dates and be able to deliver training course XYZ on June 1, two years from now.
It is the variability of those tasks in progress that require you to keep checking and correcting your course - and adding more and more detail.
This is a longer walk than I expected - the mountain looked so close! Well, I am almost there now so I better keep going...but I better grab some snacks along the way and work my way around that wet patch up ahead.
You can plan for what you can "see" - and have a rough plan for the next stages of the project journey. You can map things out in great detail to make it to the closest hill, but then you need to assess the lay of the land, navigate around the swamp you did not know was on the other side, and chart your next leg in detail to the next major point or milestone. It is in this way that we navigate through the world and through your projects, and make it to the destination on the other side.
One rule of thumb I have used in my project planning is this:
- Over the next 30 days, we can define and schedule tasks at the resolution of a day.
- Between 30-60 days, the resolution is around 2 days, give or take.
- Between 60-120 days, the resolution is at one week.
- Between 120-180 days, the resolution is at 2 weeks or more.
- Over 180 days, the resolution is at 1 month or more, and will become a summary task with more detail to be added as we get closer.
(Note that this is for duration and scheduling of assignments, not necessarily effort, though we will understand that better the closer we are to it as well).
Every time we reviewed the project plan and updated it (every month or two, if things were going relatively smoothly, or more often if not), we would review what had been accomplished so far, and then look out over the coming months and break tasks down into finer resolution and detail roughly following the model above. In this way, we had a rolling project plan with progressively more and more detail as we went along - but still a high level overview as we looked out farther into the future.
At every stage, the mountains get closer, but they are still just a little ways further off, until you finally reach your destination at the ski chalet.
The sunbather is long gone, but fortunately they left the book behind. You are also looking to rent some ski gear, because, well hey - it was a long walk and now it is early winter. But the upside is, you are here in time for ski season - and the powder is fresh, awaiting your first run. And when you finish your last run of the day, you can sit by the fire and read that book you have been looking forward to for so long.
SummaryThis article has taken us on quite a journey - from the label of a shampoo bottle to flying across the country, stopping in for an eye exam and walking long-distance to a ski resort. A mix of metaphors, perhaps, but each had a part to play in the overall lesson.
You need to be aware of your perspective when you are developing your project plan - you cannot see very many details past a fairly short period of time (weeks, or a few months). Your long-distance detail vision is not as good as you think it is. You need to Review where you are and add detail for the next group of tasks as you go.You need to make course corrections along the way. You need to Re-Plan to keep things on track, if you start to drift off course.Finally, you need to do it more than once. Perhaps not as often as an airplane, which is every few minutes - but you do need to Repeat it regularly.
So the lesson can be summarized as: "Plan your projects, and on a regular basis, Review, Re-Plan, Repeat".
Cheers and good luck with your projects. Until they develop a Project Auto-Pilot (and I hope they never do), we will just have to keep everything on track ourselves.
Gary Nelson, PMP
Gazza Consulting Services
July 15, 2012
Decisions, Decisions...A Theory on the Origin of Writing
[Also available as a podcast]
Decisions, decisions.
We each make thousands of decisions every day. Some studies have indicated that the number is at least 5,000, and possibly up to 35,000 decisions every day. Most of these are small decisions, done subconsciously, or on auto-pilot.
The conscious decisions we make every day are far fewer - but still easily in the high hundreds. The important decisions are fewer again, depending on the day. Some decisions may not even seem important until later on. But decisions we make, in the thousands, every single day of our lives. Even when you say that you can't make a decision - that is a decision to leave things as they are.
Theory on the Origin of Written LanguageI have a theory about the origin of written language. There are many in-depth philosophical, scientific and scholarly theories and analyses on the origin and stages of writing in its various forms, from proto-writing through the various scripts, hieroglyphs and alphabets.
My theory is not about the how or when of when the various forms of written language were developed as proposed by those theorists. My theory is about why written language was developed in the first place - at any place in the world you like, regardless of the time period, style, method or medium.
So here is my theory, developed over the course of an afternoon, including a short nap:
Written language was developed because of all of the decisions we make.
More specifically, the important decisions.
The Purpose of Written LanguageThe oral tradition of history is a great way to entertain and educate around campfires at night, but it is not a very reliable way of passing a consistent message across generations. Each speaker forgets a little bit, adds a little bit, or embellishes the stories a little bit. With every generation, giants get larger (8 foot! no, 9 foot! no, 11 feet tall!), enemies get more devious, more vicious, and more numerous. Heroes get more and more heroic, until they become larger than life. Details change.
The other problem is that people forget things. How many times have you been told something and then have to ask what it was they said? It may not be because you were not paying attention, it may be there was a long list of things to remember and your memory is not that good (or not as good as it was). You also have more difficulty in remembering specific details about conversations held months before, and this is normal.
Do you go to the grocery store with only a list in your head, and expect to remember to buy everything (and only those things) on your list? Rarely can any of us do that.
Decisions get made, and then they get forgotten, or miscommunicated.
I suspect that at least this much about human nature has not changed much over thousands of years.
I believe that in every culture that developed a written language, this frustration finally came to a head.
"Enough!" one leader finally would say. "I am tired of repeating myself and having things be misinterpreted. If you can't remember exactly what I am telling you, we need a better way to communicate this. I want my decisions to be clearly understood and carried out by all of my people."
It probably went something like that. Obviously not word for word, of course, as it was not written down yet (!) However, invention often comes as a result of needing to alleviate great pain, and anyone trying to rule a kingdom by the spoken word alone must have had a lot of headaches. You also had to really, really trust the people you sent out with your commands to get it right and not change it, and remember it as best they could.
So a great project would begin - to design some form of written symbols to represent the spoken language. Everyone who formed part of the communication network would have needed to be trained in the reading of the symbols, and the trusted few would be trained on inscribing the symbols.
The other benefit of a written language is that the King could expand his empire and maintain consistency of his rule - just look at the expansion of the Roman Empire as an example of what could be accomplished.
Most of the population would not have been trained in reading or writing of the symbols - it would have required a lot of effort to do so, and being able to read and write was an elite skill that formed part of the power structure. Carry the written word (symbols, hieroglyphs, script) from the central point of decision making, and then read out those words in the outlying regions - exactly as they had been inscribed at the source.
Written language symbols would have most likely been used primarily to record edicts and legal matters - important things, specifically, important decisions. Various mediums would have been tested and used - bark, cloth, animal skins, silk, reed fibre mats and others. Some were obviously more portable than others, and some more durable; some messages were of such significance that they were literally "written in stone" on rock or clay tablets, intended to last for a long time.
Babylonian legal tablet in stone envelope (Source: Wikipedia)
If you look at the various forms of written communication that have been unearthed, many of the less durable materials have decayed, but the more durable (clay tablets and stone) remain readable today. And what do we tend to find on those tablets? Decisions! Royal edicts, legal matters, business records. All outcomes of important decisions.
Very few people recorded shopping lists on stone tablets, but you can be sure there were a lot of those too, on less permanent materials. And what are shopping lists but recorded decisions of what you need to buy?
Note that literature and "pulp fiction" came much, much later - once the printed word became more accessible to the masses through the invention of the printing press.
Going forward to the present day, you will see that legacy remains - most of the written word revolves around decisions, even in fictional stories. You read about the lead-up to decisions, how people wrestle with difficult decisions, the decision as it is made, the outcome of the decisions, the justification for why they made bad decisions, and on it goes. A single book contains thousands upon thousands of decisions, and even dry textbooks describing new concepts to you are the result of others deciding what was important to tell you about the topic.
Contracts are just another form of written decisions - what has been agreed to with respect to who is going to do what, who will pay whom, and what any penalties will be for non-conformance, and so on. Requirements documents? Recorded decisions about what they want you to do.
There may be some exceptions, in some poetry perhaps, but the primary focus of the written word is still wrapped in the legacy of decision-making and recording the framework of decisions.
But is this any surprise, considering each one of us makes so many decisions, every single day?
So there is my theory. It might not even be original, as many ideas are variants of other people's ideas, but I think you will agree there is some merit to it anyway.
Your Project and Decisions How does this apply to your project? Well, in every project, there are many decisions made every single day. Some are minor, some are major and some are of great significance, either to scope, budget, time frame, or what needs to be done in order to accomplish the project goals.
Depending on the size of your project, you may have a formal Decision Log that records the disposition of major decisions that are made by the appropriate stakeholders; in your Responsibility Assignment Matrix you will have identified all of the stakeholders and project team members. A subset of these people, usually the Project Sponsor and a select group of stakeholders will be the key decision makers for your project, and you may possibly have a Change Control Board as well.
Make sure that you accurately track all of those major decisions and their outcomes, not only for the project audit, but to help ensure that everyone gets the same message about what those decisions were during your project.
For less major decisions, you may not need the Project Sponsor or the stakeholders involved; you may have these only at the level of your project team.
The decisions may relate to the scope of the project, costs, time frame, or any number of technical details regarding the execution of your project.
However, the key and important message here is to write things down . Most decisions may be arrived at through verbal discussion, but the decision and it disposition (and contributing factors) need to be recorded. This may be on paper, electronic documents or in emails, but get the information into a written form.
Don't forget to communicate the outcomes of those decisions - again, in written form. You may talk about them as well, when explaining them in front of a group, but there is more weight when things are written down.
Again, we all make thousands of decisions per day, but some need to be recorded, especially as they relate to the project. A good rule of thumb to use is if it materially affects the direction or outcomes of the project (cost, scope, timeline) or is anything that someone may come back to ask you about later on, write it down . Or type it in a log somewhere you can easily find it.
This is important because people forget, and their memories of events change and differ over time. If you write it down, both parties can review what was recorded; end of dispute over who remembered what best and who was "right"; often neither of you remember correctly.
If in doubt, write it out!
SummaryEver since High School I have written things down. You will usually find me with a notebook nearby; however these days I am able to record notes and emails on my phone, so no extra baggage required if I am out and about. But I still use a paper notebook while I work. The interesting thing I have found is that the more I write things down, the better I remember them. And if I do get fuzzy on the details later on, I know that I wrote something down about it a few months (or years) back, and am able to find the reference in a notebook. Sometimes all I write in my notebook is something to jog my memory, or a reference of where the full details are recorded elsewhere - in a document or an email. But even with that small note, I find that I am able to recall the event in detail.
Many years ago now, a customer encountered an issue that seemed familiar to me. I knew I had seen it before but could not remember the specifics or the solution - but I knew I had written it down, and approximately which month of what year (three years before). Within 10 minutes I was able to find the reference and recount the full scenario and the solution. It impressed my colleagues and the customer, but it was really a matter of making a habit of writing things down, especially the important things.
The only times I have been stuck, unable to recount the full details or an event or decision was when I neglected to record a note in my book. I may have been tired that afternoon and not felt like writing things down...and often, that would come back to bite me. So I still record notes in my notebook - and I have a closet full of them, numbered and going back many years. Of course, I use email and documents for most of my written communication these days, but the principle is the same - I can search through emails, and I will usually remember the year and month when I sent or received it as well.
Many ancient societies spent the intense effort to develop various forms of the written word, which have evolved into the various written languages we have today. And they did it all for you - and future generations, so that you can read about past decisions, and record yours for future generations, or at least for communicating within your project team (and for the project audit).
Honor the efforts of those many generations and millions of people who labored to develop the written forms of language (just for you!) - and write the important stuff down .
Good luck with your projects, and keep good notes. You'll need them for later on.
Gary Nelson, PMP
Gazza Consulting Services
Decisions, decisions.
We each make thousands of decisions every day. Some studies have indicated that the number is at least 5,000, and possibly up to 35,000 decisions every day. Most of these are small decisions, done subconsciously, or on auto-pilot.
The conscious decisions we make every day are far fewer - but still easily in the high hundreds. The important decisions are fewer again, depending on the day. Some decisions may not even seem important until later on. But decisions we make, in the thousands, every single day of our lives. Even when you say that you can't make a decision - that is a decision to leave things as they are.
Theory on the Origin of Written LanguageI have a theory about the origin of written language. There are many in-depth philosophical, scientific and scholarly theories and analyses on the origin and stages of writing in its various forms, from proto-writing through the various scripts, hieroglyphs and alphabets.
My theory is not about the how or when of when the various forms of written language were developed as proposed by those theorists. My theory is about why written language was developed in the first place - at any place in the world you like, regardless of the time period, style, method or medium.
So here is my theory, developed over the course of an afternoon, including a short nap:
Written language was developed because of all of the decisions we make.
More specifically, the important decisions.
The Purpose of Written LanguageThe oral tradition of history is a great way to entertain and educate around campfires at night, but it is not a very reliable way of passing a consistent message across generations. Each speaker forgets a little bit, adds a little bit, or embellishes the stories a little bit. With every generation, giants get larger (8 foot! no, 9 foot! no, 11 feet tall!), enemies get more devious, more vicious, and more numerous. Heroes get more and more heroic, until they become larger than life. Details change.
The other problem is that people forget things. How many times have you been told something and then have to ask what it was they said? It may not be because you were not paying attention, it may be there was a long list of things to remember and your memory is not that good (or not as good as it was). You also have more difficulty in remembering specific details about conversations held months before, and this is normal.
Do you go to the grocery store with only a list in your head, and expect to remember to buy everything (and only those things) on your list? Rarely can any of us do that.
Decisions get made, and then they get forgotten, or miscommunicated.
I suspect that at least this much about human nature has not changed much over thousands of years.
I believe that in every culture that developed a written language, this frustration finally came to a head.
"Enough!" one leader finally would say. "I am tired of repeating myself and having things be misinterpreted. If you can't remember exactly what I am telling you, we need a better way to communicate this. I want my decisions to be clearly understood and carried out by all of my people."
It probably went something like that. Obviously not word for word, of course, as it was not written down yet (!) However, invention often comes as a result of needing to alleviate great pain, and anyone trying to rule a kingdom by the spoken word alone must have had a lot of headaches. You also had to really, really trust the people you sent out with your commands to get it right and not change it, and remember it as best they could.
So a great project would begin - to design some form of written symbols to represent the spoken language. Everyone who formed part of the communication network would have needed to be trained in the reading of the symbols, and the trusted few would be trained on inscribing the symbols.
The other benefit of a written language is that the King could expand his empire and maintain consistency of his rule - just look at the expansion of the Roman Empire as an example of what could be accomplished.
Most of the population would not have been trained in reading or writing of the symbols - it would have required a lot of effort to do so, and being able to read and write was an elite skill that formed part of the power structure. Carry the written word (symbols, hieroglyphs, script) from the central point of decision making, and then read out those words in the outlying regions - exactly as they had been inscribed at the source.
Written language symbols would have most likely been used primarily to record edicts and legal matters - important things, specifically, important decisions. Various mediums would have been tested and used - bark, cloth, animal skins, silk, reed fibre mats and others. Some were obviously more portable than others, and some more durable; some messages were of such significance that they were literally "written in stone" on rock or clay tablets, intended to last for a long time.
Babylonian legal tablet in stone envelope (Source: Wikipedia)If you look at the various forms of written communication that have been unearthed, many of the less durable materials have decayed, but the more durable (clay tablets and stone) remain readable today. And what do we tend to find on those tablets? Decisions! Royal edicts, legal matters, business records. All outcomes of important decisions.
Very few people recorded shopping lists on stone tablets, but you can be sure there were a lot of those too, on less permanent materials. And what are shopping lists but recorded decisions of what you need to buy?
Note that literature and "pulp fiction" came much, much later - once the printed word became more accessible to the masses through the invention of the printing press.
Going forward to the present day, you will see that legacy remains - most of the written word revolves around decisions, even in fictional stories. You read about the lead-up to decisions, how people wrestle with difficult decisions, the decision as it is made, the outcome of the decisions, the justification for why they made bad decisions, and on it goes. A single book contains thousands upon thousands of decisions, and even dry textbooks describing new concepts to you are the result of others deciding what was important to tell you about the topic.
Contracts are just another form of written decisions - what has been agreed to with respect to who is going to do what, who will pay whom, and what any penalties will be for non-conformance, and so on. Requirements documents? Recorded decisions about what they want you to do.
There may be some exceptions, in some poetry perhaps, but the primary focus of the written word is still wrapped in the legacy of decision-making and recording the framework of decisions.
But is this any surprise, considering each one of us makes so many decisions, every single day?
So there is my theory. It might not even be original, as many ideas are variants of other people's ideas, but I think you will agree there is some merit to it anyway.
Your Project and Decisions How does this apply to your project? Well, in every project, there are many decisions made every single day. Some are minor, some are major and some are of great significance, either to scope, budget, time frame, or what needs to be done in order to accomplish the project goals.
Depending on the size of your project, you may have a formal Decision Log that records the disposition of major decisions that are made by the appropriate stakeholders; in your Responsibility Assignment Matrix you will have identified all of the stakeholders and project team members. A subset of these people, usually the Project Sponsor and a select group of stakeholders will be the key decision makers for your project, and you may possibly have a Change Control Board as well.
Make sure that you accurately track all of those major decisions and their outcomes, not only for the project audit, but to help ensure that everyone gets the same message about what those decisions were during your project.
For less major decisions, you may not need the Project Sponsor or the stakeholders involved; you may have these only at the level of your project team.
The decisions may relate to the scope of the project, costs, time frame, or any number of technical details regarding the execution of your project.
However, the key and important message here is to write things down . Most decisions may be arrived at through verbal discussion, but the decision and it disposition (and contributing factors) need to be recorded. This may be on paper, electronic documents or in emails, but get the information into a written form.
Don't forget to communicate the outcomes of those decisions - again, in written form. You may talk about them as well, when explaining them in front of a group, but there is more weight when things are written down.
Again, we all make thousands of decisions per day, but some need to be recorded, especially as they relate to the project. A good rule of thumb to use is if it materially affects the direction or outcomes of the project (cost, scope, timeline) or is anything that someone may come back to ask you about later on, write it down . Or type it in a log somewhere you can easily find it.
This is important because people forget, and their memories of events change and differ over time. If you write it down, both parties can review what was recorded; end of dispute over who remembered what best and who was "right"; often neither of you remember correctly.
If in doubt, write it out!
SummaryEver since High School I have written things down. You will usually find me with a notebook nearby; however these days I am able to record notes and emails on my phone, so no extra baggage required if I am out and about. But I still use a paper notebook while I work. The interesting thing I have found is that the more I write things down, the better I remember them. And if I do get fuzzy on the details later on, I know that I wrote something down about it a few months (or years) back, and am able to find the reference in a notebook. Sometimes all I write in my notebook is something to jog my memory, or a reference of where the full details are recorded elsewhere - in a document or an email. But even with that small note, I find that I am able to recall the event in detail.
Many years ago now, a customer encountered an issue that seemed familiar to me. I knew I had seen it before but could not remember the specifics or the solution - but I knew I had written it down, and approximately which month of what year (three years before). Within 10 minutes I was able to find the reference and recount the full scenario and the solution. It impressed my colleagues and the customer, but it was really a matter of making a habit of writing things down, especially the important things.
The only times I have been stuck, unable to recount the full details or an event or decision was when I neglected to record a note in my book. I may have been tired that afternoon and not felt like writing things down...and often, that would come back to bite me. So I still record notes in my notebook - and I have a closet full of them, numbered and going back many years. Of course, I use email and documents for most of my written communication these days, but the principle is the same - I can search through emails, and I will usually remember the year and month when I sent or received it as well.
Many ancient societies spent the intense effort to develop various forms of the written word, which have evolved into the various written languages we have today. And they did it all for you - and future generations, so that you can read about past decisions, and record yours for future generations, or at least for communicating within your project team (and for the project audit).
Honor the efforts of those many generations and millions of people who labored to develop the written forms of language (just for you!) - and write the important stuff down .
Good luck with your projects, and keep good notes. You'll need them for later on.
Gary Nelson, PMP
Gazza Consulting Services
July 2, 2012
Once Upon A Time: Your Project is a Story
[Also available as a podcast]
On July 1, 2012, my teenage son and I went to a book signing. My son's first time going to one - and it was for one of his all-time favourite authors. The author was in Hamilton, NZ for the last stop, and last "show" on his tour for the final book in the series. The next day, he was flying home.
Dragons, Magic, Dwarves, Elves, Wizards, dark forests - the core elements of every good fantasy novel are in his books.
The author spoke with the crowd for nearly an hour, telling of his journey of writing. It was quite an interesting story, and he was a dynamic speaker. At the end, during Q&A one of the members of the audience asked "how do you go about writing a book"?
The answer was insightful. His answer was that it was in exactly the same way as every other author he had met started to write their stories. The authors all started with Questions. "What if...?", "How about if the character did this...?", "Why can't we just...?" and so on.
That got me to thinking about Projects. Doesn't every project start the same way - with a lot of Questions?
Your Project is a Story Anyone who has worked on a project has a few good stories to tell about what happened on the project. And if you look at the big picture of the project, while it is happening and perhaps again in the Lessons Learned session at the end (the Epilogue), you actually have all of the elements of a great novel. You have:Characters (the Project Team and stakeholders)Action (the work of getting things done)Drama (oh boy can there be drama!)Comedy (usually unplanned but welcome nonetheless)Plot (the Project Plan, or WBS)Sub-Plot (what really happens at the lower team levels)Intrigue (Who made that change without asking?)Mystery (Will we finish this on time, in scope and on budget?)Quests (Goals)Heroes (hopefully this is all of us)Monsters (and a few nasty ones, too!)Villains (not necessarily people, this can be scope creep and the like)And sometimes, a surprise ending.So, in truth - a project really is a story! And probably a good read too, once it is all done.
Note that I am not just referring to Agile here, where the "unit of work" is referred to as a story. I am talking about the higher level genre here - independent of your system, methodology (or mythology). Projects (as a whole) are stories. Story drafts of what you would like to achieve - and the final version, where the true ending is not known until the project is finished.
The Story OutlineEvery author starts with an idea, an outline of their story that gets fleshed out as they begin to write. Chapter by chapter, the story grows - usually following the general directions of the outline they started with, but occasionally taking unexpected turns (even for the author) as the story begins to take on a life of its own.
It is much the same on our projects. We start with a high level idea, a concept during Project Initiation (the Prologue).We then get into the Planning phase (preparing for the adventure or journey). Then we are off into the wild, wild world in the Execution phase (and unlike many adventure stories, we do want most of the characters to reach the end at least mostly alive). In some stories there is certainly a lot of Executing going on! And during the execution of our projects, we often have to take unexpected turns, retrace our steps and change our plans.And finally, we reach the end - with the victory feast in the Great Hall, celebrating the victory and sharing stories and lessons learned from our travels. (Project Closeout).And overseeing it all is the Narrator (the Project Manager), subtly guiding the story (Project Control).
Crafting your Story OutlineSo you have a project to deliver. You have the high level goals, but you are not sure how to get started. You have the end in mind, but you are not sure how to get there. You need to begin crafting your story outline - how to get "there" from "here". In our projects, we have another name for this. We call it the Project Plan, or Work Breakdown Structure (WBS).
"Yes, I understand that", you say - "of course we need a Project Plan and WBS. But how do we get started?"
If you have worked on similar projects before, you will probably have a very good idea of what needs to happen when, and in what sequence. You will likely copy one of those plans, review the outline, and start tweaking it to write up your draft outline of the WBS for your new project. In this case, you are working along the lines of a "Gilt" novel. (That is not a misspelling.) Gilt, not Guilt. As in the shiny gold lettered covers of most Romance novels. We are not saying your project is going to be a romance, or that it should be treated lightly. What it means is this type of novel follows a prescribed structure, format, or formula - the basic plotline is the same "type", but the characters, location and the model of flashy sports-car the Hero (or Heroine) drives changes. If you have this type of project, you are probably off to a good start and you know most of the storyline already.
Uncharted Lands
But what about when you are working on something entirely new, or at least new to you? You need to start from scratch, taking the high level goals and breaking them down into smaller and smaller achievable pieces. You don't go straight from being a farmhand in the village to storming the castle keep in one chapter - you have to meet your band of heroes, train up, gain weapons, learn skills, buy or steal some ladders (and maybe a battering ram) before you approach the castle.
In short - we need to literally break things down into a story. You may not have castles, dragons, dungeons or swords - you may have concrete and girders, server rooms and code instead. But the principle is exactly the same.
Once Upon a Time...Every project starts with a problem to solve.
"The Princess has been kidnapped and taken to the castle!"
We need to start, as any good story does, with words. And not just any words, either. We need a few special types of words and phrases in order to define our story outline, or WBS. Same thing. We need:
Goal words and phrases. Things to be achieved. The things we need to complete, to deliver. In our story, these would be the goals of our quests. "We need to rescue the Princess!"Action words and phrases. Actions we need to take, in order to accomplish the goals and complete the Quest. "Storm the Castle" and "Save the Princess" are a good start. Note that these can also be goal words with sub-goals, but they are all about getting things done!And depending on your style (and dot the i's and cross the t's)
Completed action statements (milestones, goal achieved - so we know when we have succeeded). "Princess rescued!"
What you will find, as happens in any story, is that there is a grand vision, an overall set of lofty goals to achieve in order to solve our problems - usually at a very high level. So our initial vision statement is deceptively simple.
"Let's storm the castle and rescue the Princess!"
So, grab your pitchforks and head off into the night! ... Until the wise old man from the village (usually weatherworn, wearing a hooded cape, and a bit mysterious) calls you back and tells you that you are not ready to go quite yet. You need to Prepare, and then you can Storm the Castle and Save the Princess.
We need to prepare, and put a bit more detail into our plan. We need to think about what needs to go into the Deliverable Goals (Storm the castle) and (Save the Princess). What do we need to bring? Who do we need to go with us? What are we going to do when we get there? Once we get in, how do we get the Princess?
And on, and on. Notice the key thing here - there are lots and lots of questions. From asking the questions and figuring out the basic answers, we develop our progressively more detailed plan, with smaller and smaller goals under each higher level goal.
You keep breaking things down farther and farther until you end up with a small enough goal that one person or a small team can complete it as a Task (or Work Package) in a short period of time. Perhaps a day, or a week. But you might need a shorter timeframe on these tasks, because she is due to be executed in three days! (Ok, I made that up. The Princess is hardly ever executed or tortured. Hair messed up a bit, perhaps. But still, we have to hurry!)
If an item still seems too unwieldy to handle (like a broadsword to a dwarf), then you need to break it down still further.
" Check references? " Well, of course. You don't want to have an enemy spy in your camp, now do you? ...Oh wait, that's spoiling it for Chapter 6...
Oh, we almost forgot. We are planning a successful rescue, right? We had better plan for the Celebration of her return, as well - and start preparing details for that now!
This is how the plan evolves. We add more levels, more detail, plug in new goals as we think of them, and our story - our project - grows.
And quicker than you can say "What Dragons?" you will have a fairly decent strategy, plan, WBS, whatever - and you are all ready to go. Probably not done up in Microsoft Project, but at least sketched onto a nice piece of tanned goat hide you can roll up and take with you. Might even make a decent pillow!
You may say "Pah, that's not a realistic example - you made a WBS from a story, for a story." Well, this is true, but I assure you the same methods and rules apply - whether it is rescuing a Princess, or migrating a Server Room across to the other side of town. Give it a try!
Yes, There be Dragons Here Most projects have dragons. No, I am not kidding. Each project has seen at least one Dragon, threatening to destroy your accomplished works and progress, or consume your treasured budget, hoarding it all to itself. Here are a few dragons you might come across on your projects:
The Scope Dragon. This dragon is sometimes referred to by other names, such as "Scope creep", "creeping elegance" and the like. Note the common word "creep". This type of dragon likes to creep around, sneaking up on you and present project changes when you are at your weakest. They try to represent scope changes as "Just a small feature, we meant to have it in the specs, so pleeeeease can you do it, just this time?" This dragon has a particularly smooth-talking voice, but still has a forked tongue. Resist this dragon and its convincing spells! Pull out the mighty Specification Document (or RFP) and point out quite clearly that what they are asking for "is not a little thing" and "is not in scope".
The Cost Dragon. This dragon loves gold. Lots of gold. It likes gold so much that it will try to gold-plate everything. A deliverable looks ready to give to the customer, passed QA testing and ready to ship? Just hold on a minute, you need a bit of gold on those hubcaps. It is easy for this type of dragon to get out of control and consume your budget with much of the other work left incomplete. Beware this dragon, make sure that the team sticks to specs, delivers high quality - but no "gold plating". The Cost dragon will try to deliver a BMW when they paid for a VW; they confuse "quality" with "grade".
The Quality Dragon. The cousin of this dragon is the Cost Dragon. This little guy hides within your ranks, and its works are not always visible until it is almost too late. This can be any team member who says "well, that should be good enough" but does not make sure that it matches the specifications. Be vigilant! You don't want your sword to break at the moment you need it the most. Quality is delivering what is asked for in the specs. If they ordered a BMW, don't deliver a Volkswagen.
The Rumor Dragon. This dragon thrives on lack of coordinated information. Where there is a vacuum of information, this dragon will gladly fill it with whispers, innuendo and false information. Fighting off this dragon is relatively straightforward, but it is not easy. It requires that you develop a good Communication Plan, and that you communicate regularly to all of the stakeholder groups and users with good, solid information. Be consistent in your communication, and this dragon will wither on the sidelines.
The Subversive Dragon. A cousin to the Rumor Dragon, this type of dragon usually takes a human shape in your project, and can be difficult to spot. They may flash a toothy grin in the status meetings, but all the while they slither around behind people's backs, whispering into people's ears and stealthily work to undermine the project towards their own ends.
Even if you don't run into any of those, you will likely encounter the Time Dragon. This dragon eats up time, making things drag-on (and on and on) seemingly without any hope of reaching the light at the end of the tunnel. (In this case, we want to see daylight, not another dragon).
Beware of Dragons!
GoblinsIf you never see a dragon in your project, you still have to be watchful for the Goblins. These can be spotted by the trail of wasted time, effort and money with little to show in terms of progress. (And perhaps a few mounds of bones in KFC buckets as well).These people are literally "gobbling up" your resources, impacting your bottom line, and slowing down the progress of your project, without contributing or achieving much from them in return.
Watch out for the Project Goblins.
Dwarves, Elves, Faeries, Sprites, Nymphs and Other CharactersI don't have anything in particular to say about these folk. They don't usually cause too much trouble. Even Ogres and Giants seem to manage just fine, as long as you remember to feed them a few whole chickens from time to time.
Back to the PlanOk, we have the basic layout of the story line – the plan elements - in the WBS. We also talked about a few dangers along the way. But what about the rest of normal Project Planning? What about sequencing, dependencies, duration, effort and the Gantt chart?
Well, it turns out that anything we can put into a WBS, we can structure into a Gantt chart with all of the bells and whistles. In fact, when we look at it as a story, it is even easier to map out the sequencing and dependencies, including effort, duration, lead time/lag time and all the rest of it. Oh, and don’t forget to set your working time. They knocked off earlier than you do today - when the sun went down, it was just plain dark, except for your campfire.
SummaryMy son and I really enjoyed the book-signing session. After the session he signed books and posters, and we were 5th in line. My son got to sit beside the author for a photo, and he signed all four books (several quite dog-eared), plus the poster. A blockbuster day!
And as for projects, they truly are stories. What kind of project story will you write? Many projects start out as Adventures, or sometimes Mysteries - and the way some salespeople respond to RFPs I am sure some customers might think their project must be a Fantasy. And no matter how straightforward our outline starts out for our story, there are always twists and turns, Drama and Suspense - and the occasional Horror story too.
Good luck writing your projects, and I hope all your adventures end up with a victory feast in the Great Hall - and not with you chained up in the Dungeon.
I am not sure about you, but I can't wait to read the next one! (Project, I mean).
Although, come to think of it, I am also really looking forward to his next book...!
Gary Nelson, PMP
Gazza Consulting Services
On July 1, 2012, my teenage son and I went to a book signing. My son's first time going to one - and it was for one of his all-time favourite authors. The author was in Hamilton, NZ for the last stop, and last "show" on his tour for the final book in the series. The next day, he was flying home.
Dragons, Magic, Dwarves, Elves, Wizards, dark forests - the core elements of every good fantasy novel are in his books.
The author spoke with the crowd for nearly an hour, telling of his journey of writing. It was quite an interesting story, and he was a dynamic speaker. At the end, during Q&A one of the members of the audience asked "how do you go about writing a book"?
The answer was insightful. His answer was that it was in exactly the same way as every other author he had met started to write their stories. The authors all started with Questions. "What if...?", "How about if the character did this...?", "Why can't we just...?" and so on.
That got me to thinking about Projects. Doesn't every project start the same way - with a lot of Questions?
Your Project is a Story Anyone who has worked on a project has a few good stories to tell about what happened on the project. And if you look at the big picture of the project, while it is happening and perhaps again in the Lessons Learned session at the end (the Epilogue), you actually have all of the elements of a great novel. You have:Characters (the Project Team and stakeholders)Action (the work of getting things done)Drama (oh boy can there be drama!)Comedy (usually unplanned but welcome nonetheless)Plot (the Project Plan, or WBS)Sub-Plot (what really happens at the lower team levels)Intrigue (Who made that change without asking?)Mystery (Will we finish this on time, in scope and on budget?)Quests (Goals)Heroes (hopefully this is all of us)Monsters (and a few nasty ones, too!)Villains (not necessarily people, this can be scope creep and the like)And sometimes, a surprise ending.So, in truth - a project really is a story! And probably a good read too, once it is all done.
Note that I am not just referring to Agile here, where the "unit of work" is referred to as a story. I am talking about the higher level genre here - independent of your system, methodology (or mythology). Projects (as a whole) are stories. Story drafts of what you would like to achieve - and the final version, where the true ending is not known until the project is finished.
The Story OutlineEvery author starts with an idea, an outline of their story that gets fleshed out as they begin to write. Chapter by chapter, the story grows - usually following the general directions of the outline they started with, but occasionally taking unexpected turns (even for the author) as the story begins to take on a life of its own.
It is much the same on our projects. We start with a high level idea, a concept during Project Initiation (the Prologue).We then get into the Planning phase (preparing for the adventure or journey). Then we are off into the wild, wild world in the Execution phase (and unlike many adventure stories, we do want most of the characters to reach the end at least mostly alive). In some stories there is certainly a lot of Executing going on! And during the execution of our projects, we often have to take unexpected turns, retrace our steps and change our plans.And finally, we reach the end - with the victory feast in the Great Hall, celebrating the victory and sharing stories and lessons learned from our travels. (Project Closeout).And overseeing it all is the Narrator (the Project Manager), subtly guiding the story (Project Control).
Crafting your Story OutlineSo you have a project to deliver. You have the high level goals, but you are not sure how to get started. You have the end in mind, but you are not sure how to get there. You need to begin crafting your story outline - how to get "there" from "here". In our projects, we have another name for this. We call it the Project Plan, or Work Breakdown Structure (WBS).
"Yes, I understand that", you say - "of course we need a Project Plan and WBS. But how do we get started?"
If you have worked on similar projects before, you will probably have a very good idea of what needs to happen when, and in what sequence. You will likely copy one of those plans, review the outline, and start tweaking it to write up your draft outline of the WBS for your new project. In this case, you are working along the lines of a "Gilt" novel. (That is not a misspelling.) Gilt, not Guilt. As in the shiny gold lettered covers of most Romance novels. We are not saying your project is going to be a romance, or that it should be treated lightly. What it means is this type of novel follows a prescribed structure, format, or formula - the basic plotline is the same "type", but the characters, location and the model of flashy sports-car the Hero (or Heroine) drives changes. If you have this type of project, you are probably off to a good start and you know most of the storyline already.
Uncharted Lands
But what about when you are working on something entirely new, or at least new to you? You need to start from scratch, taking the high level goals and breaking them down into smaller and smaller achievable pieces. You don't go straight from being a farmhand in the village to storming the castle keep in one chapter - you have to meet your band of heroes, train up, gain weapons, learn skills, buy or steal some ladders (and maybe a battering ram) before you approach the castle.
In short - we need to literally break things down into a story. You may not have castles, dragons, dungeons or swords - you may have concrete and girders, server rooms and code instead. But the principle is exactly the same.
Once Upon a Time...Every project starts with a problem to solve.
"The Princess has been kidnapped and taken to the castle!"
We need to start, as any good story does, with words. And not just any words, either. We need a few special types of words and phrases in order to define our story outline, or WBS. Same thing. We need:
Goal words and phrases. Things to be achieved. The things we need to complete, to deliver. In our story, these would be the goals of our quests. "We need to rescue the Princess!"Action words and phrases. Actions we need to take, in order to accomplish the goals and complete the Quest. "Storm the Castle" and "Save the Princess" are a good start. Note that these can also be goal words with sub-goals, but they are all about getting things done!And depending on your style (and dot the i's and cross the t's)
Completed action statements (milestones, goal achieved - so we know when we have succeeded). "Princess rescued!"
What you will find, as happens in any story, is that there is a grand vision, an overall set of lofty goals to achieve in order to solve our problems - usually at a very high level. So our initial vision statement is deceptively simple.
"Let's storm the castle and rescue the Princess!"
So, grab your pitchforks and head off into the night! ... Until the wise old man from the village (usually weatherworn, wearing a hooded cape, and a bit mysterious) calls you back and tells you that you are not ready to go quite yet. You need to Prepare, and then you can Storm the Castle and Save the Princess.
We need to prepare, and put a bit more detail into our plan. We need to think about what needs to go into the Deliverable Goals (Storm the castle) and (Save the Princess). What do we need to bring? Who do we need to go with us? What are we going to do when we get there? Once we get in, how do we get the Princess?
And on, and on. Notice the key thing here - there are lots and lots of questions. From asking the questions and figuring out the basic answers, we develop our progressively more detailed plan, with smaller and smaller goals under each higher level goal.
You keep breaking things down farther and farther until you end up with a small enough goal that one person or a small team can complete it as a Task (or Work Package) in a short period of time. Perhaps a day, or a week. But you might need a shorter timeframe on these tasks, because she is due to be executed in three days! (Ok, I made that up. The Princess is hardly ever executed or tortured. Hair messed up a bit, perhaps. But still, we have to hurry!)
If an item still seems too unwieldy to handle (like a broadsword to a dwarf), then you need to break it down still further.
" Check references? " Well, of course. You don't want to have an enemy spy in your camp, now do you? ...Oh wait, that's spoiling it for Chapter 6...
Oh, we almost forgot. We are planning a successful rescue, right? We had better plan for the Celebration of her return, as well - and start preparing details for that now!
This is how the plan evolves. We add more levels, more detail, plug in new goals as we think of them, and our story - our project - grows.And quicker than you can say "What Dragons?" you will have a fairly decent strategy, plan, WBS, whatever - and you are all ready to go. Probably not done up in Microsoft Project, but at least sketched onto a nice piece of tanned goat hide you can roll up and take with you. Might even make a decent pillow!
You may say "Pah, that's not a realistic example - you made a WBS from a story, for a story." Well, this is true, but I assure you the same methods and rules apply - whether it is rescuing a Princess, or migrating a Server Room across to the other side of town. Give it a try!
Yes, There be Dragons Here Most projects have dragons. No, I am not kidding. Each project has seen at least one Dragon, threatening to destroy your accomplished works and progress, or consume your treasured budget, hoarding it all to itself. Here are a few dragons you might come across on your projects:
The Scope Dragon. This dragon is sometimes referred to by other names, such as "Scope creep", "creeping elegance" and the like. Note the common word "creep". This type of dragon likes to creep around, sneaking up on you and present project changes when you are at your weakest. They try to represent scope changes as "Just a small feature, we meant to have it in the specs, so pleeeeease can you do it, just this time?" This dragon has a particularly smooth-talking voice, but still has a forked tongue. Resist this dragon and its convincing spells! Pull out the mighty Specification Document (or RFP) and point out quite clearly that what they are asking for "is not a little thing" and "is not in scope".
The Cost Dragon. This dragon loves gold. Lots of gold. It likes gold so much that it will try to gold-plate everything. A deliverable looks ready to give to the customer, passed QA testing and ready to ship? Just hold on a minute, you need a bit of gold on those hubcaps. It is easy for this type of dragon to get out of control and consume your budget with much of the other work left incomplete. Beware this dragon, make sure that the team sticks to specs, delivers high quality - but no "gold plating". The Cost dragon will try to deliver a BMW when they paid for a VW; they confuse "quality" with "grade".
The Quality Dragon. The cousin of this dragon is the Cost Dragon. This little guy hides within your ranks, and its works are not always visible until it is almost too late. This can be any team member who says "well, that should be good enough" but does not make sure that it matches the specifications. Be vigilant! You don't want your sword to break at the moment you need it the most. Quality is delivering what is asked for in the specs. If they ordered a BMW, don't deliver a Volkswagen.
The Rumor Dragon. This dragon thrives on lack of coordinated information. Where there is a vacuum of information, this dragon will gladly fill it with whispers, innuendo and false information. Fighting off this dragon is relatively straightforward, but it is not easy. It requires that you develop a good Communication Plan, and that you communicate regularly to all of the stakeholder groups and users with good, solid information. Be consistent in your communication, and this dragon will wither on the sidelines.
The Subversive Dragon. A cousin to the Rumor Dragon, this type of dragon usually takes a human shape in your project, and can be difficult to spot. They may flash a toothy grin in the status meetings, but all the while they slither around behind people's backs, whispering into people's ears and stealthily work to undermine the project towards their own ends.
Even if you don't run into any of those, you will likely encounter the Time Dragon. This dragon eats up time, making things drag-on (and on and on) seemingly without any hope of reaching the light at the end of the tunnel. (In this case, we want to see daylight, not another dragon).
Beware of Dragons!
GoblinsIf you never see a dragon in your project, you still have to be watchful for the Goblins. These can be spotted by the trail of wasted time, effort and money with little to show in terms of progress. (And perhaps a few mounds of bones in KFC buckets as well).These people are literally "gobbling up" your resources, impacting your bottom line, and slowing down the progress of your project, without contributing or achieving much from them in return.
Watch out for the Project Goblins.
Dwarves, Elves, Faeries, Sprites, Nymphs and Other CharactersI don't have anything in particular to say about these folk. They don't usually cause too much trouble. Even Ogres and Giants seem to manage just fine, as long as you remember to feed them a few whole chickens from time to time.
Back to the PlanOk, we have the basic layout of the story line – the plan elements - in the WBS. We also talked about a few dangers along the way. But what about the rest of normal Project Planning? What about sequencing, dependencies, duration, effort and the Gantt chart?
Well, it turns out that anything we can put into a WBS, we can structure into a Gantt chart with all of the bells and whistles. In fact, when we look at it as a story, it is even easier to map out the sequencing and dependencies, including effort, duration, lead time/lag time and all the rest of it. Oh, and don’t forget to set your working time. They knocked off earlier than you do today - when the sun went down, it was just plain dark, except for your campfire.
SummaryMy son and I really enjoyed the book-signing session. After the session he signed books and posters, and we were 5th in line. My son got to sit beside the author for a photo, and he signed all four books (several quite dog-eared), plus the poster. A blockbuster day!
And as for projects, they truly are stories. What kind of project story will you write? Many projects start out as Adventures, or sometimes Mysteries - and the way some salespeople respond to RFPs I am sure some customers might think their project must be a Fantasy. And no matter how straightforward our outline starts out for our story, there are always twists and turns, Drama and Suspense - and the occasional Horror story too.
Good luck writing your projects, and I hope all your adventures end up with a victory feast in the Great Hall - and not with you chained up in the Dungeon.
I am not sure about you, but I can't wait to read the next one! (Project, I mean).
Although, come to think of it, I am also really looking forward to his next book...!
Gary Nelson, PMP
Gazza Consulting Services
June 30, 2012
Other People's Money: Managing Project Budgets Effectively
[Also available as a podcast]
Other People's Money.
(Image source: Wikipedia)
When you mention these words, some people might think of stock markets, mutual funds, and the 1991 movie by the same name starring Danny DeVito, in which he played a ruthless corporate raider, leading hostile takeovers of other companies using everyone's money but his own. You might then think about recent history and failed banks, brokerage firms and the millions of affected people when their retirement investments shrank or fell to near zero and countless people lost their homes.
Scary, scary stuff.
Well, let's step back from the big scary picture out there. Back to the reality of your project, where you are "in charge". All of that scary stuff does not really apply to you, does it?
Well, unless you have zero control over your project (and you are just watching from the sidelines and not doing your job), it does apply to you. Unless you are Richard Branson or Bill Gates, you are probably not bankrolling this project from your own pocket.
Your entire project is funded by Other People's Money. This may be customer money, corporate internal project money, or the collected money from the bake sale last month.
The Bad News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.
The Good News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.
The Good News and the Bad NewsHow can this be both good and bad news? Well, if things go sour and you did not manage scope, effort and budget effectively - there will be wastage and you will likely run out of money before the project is finished. You are accountable, it will be "your fault".
The good news is that unless you are hamstrung in managing your projects by sneak-around requests to the CEO that end up blowing out scope (but with no increase in budget), you are in charge. And even in that scenario, if you manage it effectively and are able to handle the change requests for increased budget, you are still "in control".
Well at least the common perception is that you are in control - you have the authority to manage the resources and activities on your project. And often, that is all you really need - formal or informal authority discussions aside.
You might have full disclosure of the internal cost and external billing rates for every one of your team members, or you may only know the overall billing rate to the client. Or if this is an internal project, you may only know the hours budgeted and not hourly rates.
But you can still work with the information you have.
Creating the Budget: EstimatingDepending when you got involved with the project, you may have been involved with the estimating & budgeting process, or the overall budget may just be handed over to you. But if you are helping to define the project budget, read on:
There are many models for estimating in different industries, so I won't go over any detailed specifics of what the best estimate is for service X in scenario Y. These are things that will have many contributing factors based on your industry, the environment, delivery schedule and so on.
But in general - you should plan for a few surprises. Build in a "buffer" or a reserve, that can only be tapped if needed. In some industries, a 10% buffer is recommended. In a low-risk project environment, 5% may be enough. But if there is a high level of risk and uncertainty, you may want a reserve buffer as high as 30% or more of what your overall estimate is "to get the job done".
Note that the Project Manager may also build in a (much) smaller buffer for resource flexibility - perhaps earmark an additional resource that might be needed for a portion of the project, for example.
There are different methods on how you can do this. You may build it into the overall budget itself, or you can work with the client to have them secure separate funding in that amount, that can only be drawn against by formal request of the Change Control Board.
There are pros and cons to both approaches; if it is within the actual budgeted PO for you to manage, you have more flexibility in managing and juggling funds within the project, without a lot of red tape. Of course, then you have to also make sure that you track very carefully and don't "touch" those funds without joint agreement with the customer. From the customer's perspective, if all of the funds, including the buffer, are "accessible" and under the same PO, then they might realistically feel that the money will be spent - and that someone will find a reason to spend it.
If, on the other hand, it is really "emergency money" and the customer retains it in their coffers, doling out small PO's for clusters of change requests, they may feel more secure that any un-spent money can be saved for a rainy day and other projects after this one. This will add more overhead to the process, but it is an equally justifiable approach.
It is a matter of trust, on both sides as to who "holds the buffer", or at least, the potential to get at it most easily.
You need to look at it from both levels - the PM needs a bit of flexibility in juggling hours and adapting to events without appealing to the Change Control Board, but the really big stuff should go through the CCB.
On one of my projects, I included a few extra weeks of training that were likely to be needed but might not, depending how things went - so those training days served as a small internal pool of hours that we were able to use for other things near the end of the project when it turned out the training was not needed.
Managing the BudgetWell, now you have your budget. Your overall pool of hours, resources, equipment costs, all to be managed. The budget may be based on a detailed project plan, but more likely it will be based on an RFP response which used high level estimates of what type of work needs to be done. You then need to flesh out your Project Plan - and Resource Plan - based on what actually needs to be done and when, under your ceiling of hours.
This will involve a lot of juggling on your part, working with your team leads to make sure that you have enough, but not too many resources on any particular set of tasks at any point in the project. If it sounds like a lot of work, it is - but quite essential. This is why you are the Project Manager, after all.
Of course, things are constantly changing - and the larger your project (and budget), the more things there are going on, and the greater likelihood of surprises. So you need to keep on top of the budget, the resource plan and what is coming up next. There may be delays which mean that you don't need resource X on the project until June 20 instead of May 30, so you had better make those changes quickly or you will end up burning hours while they cool their heels waiting for work to do.
You should be reviewing your budget and resource planning regularly - at least monthly, but also be aware of what is going on day-to-day in your project. Something might come up in the status meeting or be brought to your attention that requires an immediate adjustment to plan (and resources or equipment) that cannot wait for the monthly budget review. You may need to add or trim hours on an ongoing basis.
Ah, the life of the Project Manager!
Budget vs Actuals vs ForecastOn one of my projects, there were seven different resource cost and billing rates for the different types of resources utilized on the project (people, not equipment). One of the challenges I faced early on in the project was trying to get a good handle of where we actually were in terms of tracking to budget, in the midst of a lot of changes.
Of course, we had the invoice history and the details from Finance - monthly, but that was not quite enough for managing a fast-paced project. Also, with the variable billing rates of the different resources we had on-and-off-site (with different rates for on and off-site, so 14 billing rates), we had to be able to forecast in great detail, while also reconciling the actuals for auditing purposes.
Note: since that project, the company decided to go to a universal billing rate, regardless of the skill level. The only variations now are on-and-offsite rates. Almost too simple!
Previously on other projects, the PMs were tracking actual $ and forecasting hours - but this left a lot of room for error due to the multiple billing rate model. Then there were the inevitable credits issued to the customer that had to be accounted for too.
So I combined the actuals and forecasting data into one complex spreadsheet, where we reviewed the actuals and managed the forecast with the client on a monthly basis, and during the meeting we were able to immediately view the net$ impact of tweaking the different classes of resource assignments, down to the penny. As actuals came in, these replaced the forecast amounts, and we could also see the variance of the actuals vs forecast by resource and month, all in one place. We were then able to easily adjust going forward, where last month was 6 days under-spent on resource X but two days over on resource Y, and so on.
This gave the customer a great deal of confidence in the overall management of the project, and also gave them input to the resource adjustments for the upcoming months. As this was a 3-year, $5M project, having forecasting capability to that level of detail was extremely helpful, and the monthly budget meetings proved sufficient to avoid any real surprises.
And in the end - we delivered the project successfully, and under budget.
Managing Expenses: I've Got A Coupon For That!
On most projects, the expenses were relatively predictable. Airfare, Hotel, Car, Meals (no alcohol). We carpooled based on the number of resources in town at any point in time, stayed at the project hotel, and the airfares were pretty predictable. Meals were capped at $45USD per day, total.
From a budgeting/forecasting perspective, there was not a huge degree of variance.
Except for one person who I met on that project, and have worked with closely for many years since (and is also a good friend).
He was not wasteful, far from it. He does not drink (well, water and soft drinks, yes). And with a limit of $45/day, you could not really go too far astray - any excess was from your own pocket. He was also extremely generous to a fault, bringing in chocolate to the office on a regular basis.
But only when it was on sale or he had a coupon.
Yes, he was generous - but extremely frugal with his money, and especially Other People's Money. Even though we were on expenses, he took it as a personal challenge to save the project money. Not just him, but the group of us!
He scoured the papers for coupons, bought the Entertainment Coupon Book, and when he ate out, it was almost always a place he had a coupon for. And he never ate alone. He was great company to be with, but the other reason was that most of the coupons were 2-for-1. Of course, he also shared the coupons with us in case we were not dining with him that day.
He came into the office one morning beaming from ear to ear. He had just bought a pen from CVS the day before. He had a CVS cash-back voucher, a coupon and a rebate for the pen that he could use together. Including the price of the envelope and the stamp for sending in the rebate, they were paying him $0.55 to take that $3.50 pen home. Now that is effective fiscal management!
When we had completed the main project deliverables and I returned to the head office (still doing some remote PM for the customer), we were able to keep him on-site for a good portion of the following year, based on the budgeted funds that were left over. We joked with him that his Coupon-clipping had "saved him into a year's employment". A bit of an exaggeration, but not much. He definitely contributed to the overall project ethos of "eat well but save money" that did end up saving us a lot of money for the project - and it was fun, too.
SummaryFiscal accountability is what it is all about - being a conscientous steward of Other People's Money on your project. I am not saying there will not be some wastage, there always is some time or material that is not used quite as effectively as it could be. But if you keep in mind that the funds from your project are the result of someone else's hard-saved or hard-earned efforts, you will be able to keep the big picture in your head a bit more clearly.
It is not about spending the entire budget, reaching your corporate fiscal targets this quarter, or looking at it as a steady paycheck for a period of time. It is about doing things right - to the best of your ability, and respecting the investment they have in you - to invest their money wisely in the delivery of the project.
Good luck with your projects, manage those project budgets wisely, and when you next eat out, there might just be a coupon for that!
And as for me? I am going out to have a coffee with my wife (2-for-1 card).
Cheers!
Gary Nelson, PMP
Gazza Consulting Services
Other People's Money.
(Image source: Wikipedia) When you mention these words, some people might think of stock markets, mutual funds, and the 1991 movie by the same name starring Danny DeVito, in which he played a ruthless corporate raider, leading hostile takeovers of other companies using everyone's money but his own. You might then think about recent history and failed banks, brokerage firms and the millions of affected people when their retirement investments shrank or fell to near zero and countless people lost their homes.
Scary, scary stuff.
Well, let's step back from the big scary picture out there. Back to the reality of your project, where you are "in charge". All of that scary stuff does not really apply to you, does it?
Well, unless you have zero control over your project (and you are just watching from the sidelines and not doing your job), it does apply to you. Unless you are Richard Branson or Bill Gates, you are probably not bankrolling this project from your own pocket.
Your entire project is funded by Other People's Money. This may be customer money, corporate internal project money, or the collected money from the bake sale last month.
The Bad News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.
The Good News? You are the steward and caretaker of Other People's Money, entrusted to deliver the project outcomes successfully - within scope, on time, and of course - on or under budget.
The Good News and the Bad NewsHow can this be both good and bad news? Well, if things go sour and you did not manage scope, effort and budget effectively - there will be wastage and you will likely run out of money before the project is finished. You are accountable, it will be "your fault".
The good news is that unless you are hamstrung in managing your projects by sneak-around requests to the CEO that end up blowing out scope (but with no increase in budget), you are in charge. And even in that scenario, if you manage it effectively and are able to handle the change requests for increased budget, you are still "in control".
Well at least the common perception is that you are in control - you have the authority to manage the resources and activities on your project. And often, that is all you really need - formal or informal authority discussions aside.
You might have full disclosure of the internal cost and external billing rates for every one of your team members, or you may only know the overall billing rate to the client. Or if this is an internal project, you may only know the hours budgeted and not hourly rates.
But you can still work with the information you have.
Creating the Budget: EstimatingDepending when you got involved with the project, you may have been involved with the estimating & budgeting process, or the overall budget may just be handed over to you. But if you are helping to define the project budget, read on:
There are many models for estimating in different industries, so I won't go over any detailed specifics of what the best estimate is for service X in scenario Y. These are things that will have many contributing factors based on your industry, the environment, delivery schedule and so on.
But in general - you should plan for a few surprises. Build in a "buffer" or a reserve, that can only be tapped if needed. In some industries, a 10% buffer is recommended. In a low-risk project environment, 5% may be enough. But if there is a high level of risk and uncertainty, you may want a reserve buffer as high as 30% or more of what your overall estimate is "to get the job done".
Note that the Project Manager may also build in a (much) smaller buffer for resource flexibility - perhaps earmark an additional resource that might be needed for a portion of the project, for example.
There are different methods on how you can do this. You may build it into the overall budget itself, or you can work with the client to have them secure separate funding in that amount, that can only be drawn against by formal request of the Change Control Board.
There are pros and cons to both approaches; if it is within the actual budgeted PO for you to manage, you have more flexibility in managing and juggling funds within the project, without a lot of red tape. Of course, then you have to also make sure that you track very carefully and don't "touch" those funds without joint agreement with the customer. From the customer's perspective, if all of the funds, including the buffer, are "accessible" and under the same PO, then they might realistically feel that the money will be spent - and that someone will find a reason to spend it.
If, on the other hand, it is really "emergency money" and the customer retains it in their coffers, doling out small PO's for clusters of change requests, they may feel more secure that any un-spent money can be saved for a rainy day and other projects after this one. This will add more overhead to the process, but it is an equally justifiable approach.
It is a matter of trust, on both sides as to who "holds the buffer", or at least, the potential to get at it most easily.
You need to look at it from both levels - the PM needs a bit of flexibility in juggling hours and adapting to events without appealing to the Change Control Board, but the really big stuff should go through the CCB.
On one of my projects, I included a few extra weeks of training that were likely to be needed but might not, depending how things went - so those training days served as a small internal pool of hours that we were able to use for other things near the end of the project when it turned out the training was not needed.
Managing the BudgetWell, now you have your budget. Your overall pool of hours, resources, equipment costs, all to be managed. The budget may be based on a detailed project plan, but more likely it will be based on an RFP response which used high level estimates of what type of work needs to be done. You then need to flesh out your Project Plan - and Resource Plan - based on what actually needs to be done and when, under your ceiling of hours.
This will involve a lot of juggling on your part, working with your team leads to make sure that you have enough, but not too many resources on any particular set of tasks at any point in the project. If it sounds like a lot of work, it is - but quite essential. This is why you are the Project Manager, after all.
Of course, things are constantly changing - and the larger your project (and budget), the more things there are going on, and the greater likelihood of surprises. So you need to keep on top of the budget, the resource plan and what is coming up next. There may be delays which mean that you don't need resource X on the project until June 20 instead of May 30, so you had better make those changes quickly or you will end up burning hours while they cool their heels waiting for work to do.
You should be reviewing your budget and resource planning regularly - at least monthly, but also be aware of what is going on day-to-day in your project. Something might come up in the status meeting or be brought to your attention that requires an immediate adjustment to plan (and resources or equipment) that cannot wait for the monthly budget review. You may need to add or trim hours on an ongoing basis.
Ah, the life of the Project Manager!
Budget vs Actuals vs ForecastOn one of my projects, there were seven different resource cost and billing rates for the different types of resources utilized on the project (people, not equipment). One of the challenges I faced early on in the project was trying to get a good handle of where we actually were in terms of tracking to budget, in the midst of a lot of changes.
Of course, we had the invoice history and the details from Finance - monthly, but that was not quite enough for managing a fast-paced project. Also, with the variable billing rates of the different resources we had on-and-off-site (with different rates for on and off-site, so 14 billing rates), we had to be able to forecast in great detail, while also reconciling the actuals for auditing purposes.
Note: since that project, the company decided to go to a universal billing rate, regardless of the skill level. The only variations now are on-and-offsite rates. Almost too simple!
Previously on other projects, the PMs were tracking actual $ and forecasting hours - but this left a lot of room for error due to the multiple billing rate model. Then there were the inevitable credits issued to the customer that had to be accounted for too.
So I combined the actuals and forecasting data into one complex spreadsheet, where we reviewed the actuals and managed the forecast with the client on a monthly basis, and during the meeting we were able to immediately view the net$ impact of tweaking the different classes of resource assignments, down to the penny. As actuals came in, these replaced the forecast amounts, and we could also see the variance of the actuals vs forecast by resource and month, all in one place. We were then able to easily adjust going forward, where last month was 6 days under-spent on resource X but two days over on resource Y, and so on.
This gave the customer a great deal of confidence in the overall management of the project, and also gave them input to the resource adjustments for the upcoming months. As this was a 3-year, $5M project, having forecasting capability to that level of detail was extremely helpful, and the monthly budget meetings proved sufficient to avoid any real surprises.
And in the end - we delivered the project successfully, and under budget.
Managing Expenses: I've Got A Coupon For That!
On most projects, the expenses were relatively predictable. Airfare, Hotel, Car, Meals (no alcohol). We carpooled based on the number of resources in town at any point in time, stayed at the project hotel, and the airfares were pretty predictable. Meals were capped at $45USD per day, total.
From a budgeting/forecasting perspective, there was not a huge degree of variance.
Except for one person who I met on that project, and have worked with closely for many years since (and is also a good friend).
He was not wasteful, far from it. He does not drink (well, water and soft drinks, yes). And with a limit of $45/day, you could not really go too far astray - any excess was from your own pocket. He was also extremely generous to a fault, bringing in chocolate to the office on a regular basis.
But only when it was on sale or he had a coupon.
Yes, he was generous - but extremely frugal with his money, and especially Other People's Money. Even though we were on expenses, he took it as a personal challenge to save the project money. Not just him, but the group of us!
He scoured the papers for coupons, bought the Entertainment Coupon Book, and when he ate out, it was almost always a place he had a coupon for. And he never ate alone. He was great company to be with, but the other reason was that most of the coupons were 2-for-1. Of course, he also shared the coupons with us in case we were not dining with him that day.
He came into the office one morning beaming from ear to ear. He had just bought a pen from CVS the day before. He had a CVS cash-back voucher, a coupon and a rebate for the pen that he could use together. Including the price of the envelope and the stamp for sending in the rebate, they were paying him $0.55 to take that $3.50 pen home. Now that is effective fiscal management!
When we had completed the main project deliverables and I returned to the head office (still doing some remote PM for the customer), we were able to keep him on-site for a good portion of the following year, based on the budgeted funds that were left over. We joked with him that his Coupon-clipping had "saved him into a year's employment". A bit of an exaggeration, but not much. He definitely contributed to the overall project ethos of "eat well but save money" that did end up saving us a lot of money for the project - and it was fun, too.
SummaryFiscal accountability is what it is all about - being a conscientous steward of Other People's Money on your project. I am not saying there will not be some wastage, there always is some time or material that is not used quite as effectively as it could be. But if you keep in mind that the funds from your project are the result of someone else's hard-saved or hard-earned efforts, you will be able to keep the big picture in your head a bit more clearly.
It is not about spending the entire budget, reaching your corporate fiscal targets this quarter, or looking at it as a steady paycheck for a period of time. It is about doing things right - to the best of your ability, and respecting the investment they have in you - to invest their money wisely in the delivery of the project.
Good luck with your projects, manage those project budgets wisely, and when you next eat out, there might just be a coupon for that!
And as for me? I am going out to have a coffee with my wife (2-for-1 card).
Cheers!
Gary Nelson, PMP
Gazza Consulting Services
June 27, 2012
Implementing Organizational Change? Learn How to Grow a Desert
[Also available as a podcast]
All projects are change projects. That is the nature of projects – to create something new, to improve processes or to introduce something new into the business – and all of this requires people to adapt to the change. To better learn how to approach change - especially organizational change, we need to take a trip to a place that seems timeless, but is constantly changing.
White Sands, New Mexico - home to the largest gypsum dune field in the world, covering 275 square miles (712 sq km).
The glistening dunes of the White Sands desert are one of the wonders of the world, rising from the Tularosa basin on the eastern edge of the San Andres mountain range. Every year they slowly advance eastward across the Tularosa basin towards Alamogordo.
Gypsum sand is not a "normal" sand. Usually a desert like this would not even exist - gypsum is highly soluble and usually washes out of the hills and works its way down to the sea through streams and rivers.
In fact, the Tularosa basin used to be part of an inland sea, created by a massive rift when the continental plates pulled apart - but now it is a land-locked desert basin. It is part of the Chihuahuan Desert, seeing only a few inches of rain a year with no rivers to carry moisture (or gypsum) away.
The desert basin is also very flat - really flat, as only the bottom of an old sea or lake can be. When driving up to White Sands from El Paso, I literally drove in a straight line at 70mph/113kph (yes the speed limit) for an hour or more. And it felt like I was crawling.
The White Sands dune field is a good model for looking at Organizational change - progress can often be slow and steady, with occasional bursts of movement. From a distance, change may not even be apparent at all over short periods of time. And with the "wrong" environmental factors, progress can be literally washed away. But with persistence and the right change agents working together, you can move mountains.
Recipe for Change: Growing a Desert, Step-by-Step Interestingly enough, you need the some of the same basic ingredients to grow a gypsum desert as you do to grow plants.
MineralsWaterSunlightAir
When you want to grow a plant, you need the seed and (1) minerals [in soil], (2) water, (3) sunlight, (4) air, all in balance. Too much (or too little) of any one of these four, and your seedling will die.
In the case of growing a gypsum desert, you need (1) the mineral gypsum - from the surrounding mountain ranges, and (2) water, (3) sunlight and (4) air - specifically, wind. You need some energy, a push to get things moving. Too much (or too little) of any one of these four, and you will not have your gypsum desert.
Too little water, and the gypsum won't dissolve out of the mountains Too much water, and the gypsum will stay in solution in the lake water Too little sun, and you can't precipitate the salts out of the water (less evaporation)Too little wind, and you have no crystal erosion or movement of sandToo much wind - and it all blows away!There is of course one major difference between a desert and an organization. You would never ask a grain of sand if it wanted to be part of a sand dune. It is just part of being a grain of sand to be part of a beach or a dune - it is in its nature. All it takes is a bit of wind or wave action, and it moves.
However, in an organization, you have people, not sand - and people can provide disproportionate levels of resistance to change relative to their "size". It is just part of being a person - it is in our nature to resist change.
When planning for and implementing organizational change, you need to start with these basic ingredients:
Vision of the futureReason for the change (why "there" will be better than "here")Change Agents (people who buy-in and help introduce the change)Energy and determination to persevere
Moving the MountainPeople simply don’t like change. If things are going along “well enough”, people will generally not want to change – they will stick with their ingrained habits and procedures. And not only will they not want to change – they will, either actively or passively, resist it. They want to remain part of the mountain.
We need to help start them on the journey to change. And it won't be a smooth road either - there will be stops and starts along the way.
Just Add Water
Infrequent seasonal rains dissolve gypsum from the light stratus layers in the mountains, bringing it to the low point near Lake Lucero.
In projects, you need to prepare for change by looking at the current state and the desired future state. You also need to look at the organizational culture to see what approaches may or may not work, and look at what has worked in the past.
Generally, a "hit them hard and fast" approach never turns out well in the long term. If things have been pretty stable for a long time, you need to take a softer approach to start - you need to assess the lay of the land carefully, test the waters, talk to people in the different areas where you are trying to effect the change.
You will likely only find a few people that welcome change with open arms – these are the early adopters, and they can prove to be your greatest advocates. Ideally, you will be able to identify and bring advocates on board from each of the to-be-affected areas of the organization.
Then, you begin to craft your message. Your Communication Plan is a key component of any change management strategy, and can literally be the make-or-break factor for your project change efforts. Take the time to invest effort in it, and invest your efforts wisely. The form and size of the communication plan and your change management team (including the advocates) will vary depending upon the scale and strategic importance of your project.
I would even suggest creating a storyboard - laying out the overall message for what we are changing, why the change is needed, and setup a progressive strategy for different levels of detail in the messages for the different audiences as you go forward.
You may not be permitted a lot of time to invest in your change management plan up front before you have to start communicating to the end users. However, it is important to layout the overall strategy, with plans to adapt when things don't quite turn out the way you hoped. Design the initial communications in detail - with the big picture sketched out, to be filled in as you go.
Once you have crafted your initial messages, use your advocates and the appropriate communication channels to spread the word, to soften up people's attitudes and begin to dissolve initial resistance, like gypsum in rain water.
Turning up the HeatOnce in the lake and alkali flats, sunlight begins to evaporate the gypsum-rich water, forming columns of the soft crystal Selenite.
Ok, so you have things started - the initial messages are out and circulating with your end user "audience".
"That's interesting" they say.
You got them loosened up a bit, noses above the cubicle walls, but then they settle back and go back to doing things the way they always did.
Almost . They are not exactly as they were before - you moved them a bit, but without any further actions from you, they will simply go back to their old ways - re-crystalizing where they now stand.
Believe it or not, this is not a bad thing - you have at least got them used to the idea of change. And it didn't hurt too bad yet, did it?
But this is not quite good enough yet - we need to put a bit more pressure on, turn the heat up, and put some more effort and energy into the process.
Shaken, Not Stirred
As the lake dries up further, wind and friction from other gypsum chunks break the crystal columns apart, bashing the pieces together over and over again until they break down to the size of a grain of sand.
For most people there has to be a compelling need in order to adopt change – and this can either be to improve from a very negative condition, or to adopt something new that will make things much easier for them. And even in these cases, they will not embrace change with open arms – there will still be doubts and uncertainty. (The devil you know vs the devil you don't)
We need to introduce a bit of discomfort . (Humanely, of course). Oh, and some Hope too.
We need to shake things up!
If we truly want the change to be effective, we need to have people wanting to change. We can't actually make them change. They have to do it themselves. And the only way to do this is to make the future state look and be much more appealing than the current state. (The "carrot".)
We need to crank up the communications and story-writing (truthfully of course), painting pictures of how things will be better with [the new system, product, process, whatever].
"That's nice," they say "but I like it the way it is now. Sounds ok, but I'm not changing."
We also need to carefully and selectively apply the "stick" to help move things in the right direction. You need to make it clear that it will be quite uncomfortable to remain "as is" - perhaps the system is being replaced and decommissioned, so the old one can't be used anymore. Or perhaps the job descriptions are changing and you need to "tool up" if you want to remain employed. There are less drastic scenarios in the middle ground as well - but the point is, you want them to move. If they are nice and cozy right where they are - most people will simply not adopt the change, and you will languish as your project sputters out and eventually fails.
Again - use your advocates at the grass roots to help manage the change and have their ears and eyes monitoring the mood and reaction with their peers; you need a feedback loop to the project team. However, the main push for this phase needs to have official, higher level support and enforcement.
Build Momentum
When the wind reaches approximately 20pmh/32kph, it is strong enough to blow the individual grains eastward into the dunes, one grain at a time.
Ok, now you have people starting to go your way - the masses are starting to move. Slowly at first, but the momentum starts to build.
Don't give up on your efforts now, though - you need to keep the communications and monitoring efforts going, to make sure that progress is being made. If you let it lapse, the wind will die down and you will stop making forward progress.
And don't forget to publicize any successes and milestone achievements along the way ("1,000th PC upgraded/user migrated, etc), as this will also help keep up the forward momentum.
Success promotes success!
Handling ResistanceSome resistance is inevitable, but unless it is a big enough obstacle, it should not impede the overall progress of your efforts - if you are prepared, that is!
Resistors - You can’t avoid them; there will always be at least one, so you had better be prepared. There are three types of resistance –passive, active, and subversive.
Passive Resistors: These are by nature the hardest to spot. They will quietly resist your efforts, but it is unlikely that they will spread the word very far. You need to remember they are there, but don’t need to put much effort into handling them for the most part. It is likely that they will gradually become “reluctant adopters” and then “users” as their peers gradually adopt around them.Active Dissenters: These people can seem to be your biggest headache. They are generally quite outspoken, even more than the advocates. Their tirades can bring many of the “undecided” over to their side of non-adoption, so you can end up with a steep slope to climb. The trick is to identify them early – and bring them into the fold. (Keep your friends close and your enemies closer – Sun-tzu). Yes, bring them onto the Project Team. Not only that – give them a job to do, and listen to their input.
Many dissenters are simply people seeking to have their opinion valued – and if you can manage to “convert them” to the project’s goals while also demonstrating that you value their opinion, you can end up with some of your most influential advocates. At worst, if you are keeping close tabs on them, as part of the team they are less likely to be destructive as it will reflect badly on them too.
So they won’t join “the dark side” of the project team? Still keep a watchful eye on them, and try to involve them. Don’t give up – you may still be able to bring them in line with the project.Subversives: These are the ones that smile to your face and talk behind your back (or stab you in the back). We had one of these on one of my projects – he had built a "side" system that was to be decommissioned, and simply did not want to let it go.
Even though there was a company-wide edict from the CEO to adopt the new system and close down the “old” internal one, he went around behind and whispered into key ears, which ended up interfering with the adoption of the new system in multiple locations. Not completely, but there were complications that delayed buy-in.
Sometimes it’s simply down to who you know, not what you know. Be careful of the subversives! You may not be able to diffuse them, but you can’t ignore them either. You will need to figure out ways to counter their back-door rebellion – likely on an ongoing basis, unfortunately.Don't make the mistake of ignoring your resistors - they can quite easily hamstring your project and bring things to a complete halt.
In the worst-case scenario, they can set you back quite a bit in both progress and credibility as they undermine what you are trying to achieve. In White Sands, the equivalent would be a heavy downpour dissolving large quantities of gypsum sand, erasing progress and shrinking the dunes.
The Tipping PointThe wind lifts and rolls the individual grains up the windward side of the dune, until they collect at the crest. The gypsum sand grains build up into a sharp edge or overhang until gravity pulls them down the leeward face, moving the dune slowly forward, inch by inch. (Sometimes a helping boot may give it a little nudge, moving the dune forward just that small fraction faster).
And there we have it - progress may have seemed slow, always uphill - but eventually, we reach a critical mass on the path to change, and it eventually becomes self-sustaining; we have reached the point of collective buy-in.
Well, at least for the first key group of users, but the others are not far behind, and will be soon coming over the crest, a group at a time.
Again - don't stop your change management and communication efforts just yet - you still need to keep the message going, and advertise success stories.
But at this stage - you are not having to work quite as hard. The masses are moving together, following the advocates and their "peer leaders". All you need from the project team is the occasional "nudge of a boot" on the crest if gravity "seems a little slow taking over", and regular monitoring to make sure that things remain on track.
And then, suddenly we are there! It may have been a long process and a lot of effort, but you have grown your own desert. Well, implemented the organizational change you needed for your project, anyway.
Congratulations!
Summary
Growing a desert has many parallels with driving cultural or organizational change on your projects. In fact, when trying to implement organizational change, you might feel like you are stranded out alone in the desert all by yourself.
But with the right conditions, the right ingredients, and energy/effort applied in the right places at the right points, you can literally move mountains.
And on a side note - when you look really close, the desert is not a barren place at all. It is full of life - and hope.
Good luck with your projects and implementing change!
Gary Nelson, PMP
Gazza Consulting Services
All projects are change projects. That is the nature of projects – to create something new, to improve processes or to introduce something new into the business – and all of this requires people to adapt to the change. To better learn how to approach change - especially organizational change, we need to take a trip to a place that seems timeless, but is constantly changing.
White Sands, New Mexico - home to the largest gypsum dune field in the world, covering 275 square miles (712 sq km).
The glistening dunes of the White Sands desert are one of the wonders of the world, rising from the Tularosa basin on the eastern edge of the San Andres mountain range. Every year they slowly advance eastward across the Tularosa basin towards Alamogordo.
Gypsum sand is not a "normal" sand. Usually a desert like this would not even exist - gypsum is highly soluble and usually washes out of the hills and works its way down to the sea through streams and rivers.
In fact, the Tularosa basin used to be part of an inland sea, created by a massive rift when the continental plates pulled apart - but now it is a land-locked desert basin. It is part of the Chihuahuan Desert, seeing only a few inches of rain a year with no rivers to carry moisture (or gypsum) away.
The desert basin is also very flat - really flat, as only the bottom of an old sea or lake can be. When driving up to White Sands from El Paso, I literally drove in a straight line at 70mph/113kph (yes the speed limit) for an hour or more. And it felt like I was crawling.
The White Sands dune field is a good model for looking at Organizational change - progress can often be slow and steady, with occasional bursts of movement. From a distance, change may not even be apparent at all over short periods of time. And with the "wrong" environmental factors, progress can be literally washed away. But with persistence and the right change agents working together, you can move mountains.
Recipe for Change: Growing a Desert, Step-by-Step Interestingly enough, you need the some of the same basic ingredients to grow a gypsum desert as you do to grow plants.
MineralsWaterSunlightAir
When you want to grow a plant, you need the seed and (1) minerals [in soil], (2) water, (3) sunlight, (4) air, all in balance. Too much (or too little) of any one of these four, and your seedling will die.
In the case of growing a gypsum desert, you need (1) the mineral gypsum - from the surrounding mountain ranges, and (2) water, (3) sunlight and (4) air - specifically, wind. You need some energy, a push to get things moving. Too much (or too little) of any one of these four, and you will not have your gypsum desert.
Too little water, and the gypsum won't dissolve out of the mountains Too much water, and the gypsum will stay in solution in the lake water Too little sun, and you can't precipitate the salts out of the water (less evaporation)Too little wind, and you have no crystal erosion or movement of sandToo much wind - and it all blows away!There is of course one major difference between a desert and an organization. You would never ask a grain of sand if it wanted to be part of a sand dune. It is just part of being a grain of sand to be part of a beach or a dune - it is in its nature. All it takes is a bit of wind or wave action, and it moves.
However, in an organization, you have people, not sand - and people can provide disproportionate levels of resistance to change relative to their "size". It is just part of being a person - it is in our nature to resist change.
When planning for and implementing organizational change, you need to start with these basic ingredients:
Vision of the futureReason for the change (why "there" will be better than "here")Change Agents (people who buy-in and help introduce the change)Energy and determination to persevere
Moving the MountainPeople simply don’t like change. If things are going along “well enough”, people will generally not want to change – they will stick with their ingrained habits and procedures. And not only will they not want to change – they will, either actively or passively, resist it. They want to remain part of the mountain.
We need to help start them on the journey to change. And it won't be a smooth road either - there will be stops and starts along the way.
Just Add Water
Infrequent seasonal rains dissolve gypsum from the light stratus layers in the mountains, bringing it to the low point near Lake Lucero.
In projects, you need to prepare for change by looking at the current state and the desired future state. You also need to look at the organizational culture to see what approaches may or may not work, and look at what has worked in the past.
Generally, a "hit them hard and fast" approach never turns out well in the long term. If things have been pretty stable for a long time, you need to take a softer approach to start - you need to assess the lay of the land carefully, test the waters, talk to people in the different areas where you are trying to effect the change.
You will likely only find a few people that welcome change with open arms – these are the early adopters, and they can prove to be your greatest advocates. Ideally, you will be able to identify and bring advocates on board from each of the to-be-affected areas of the organization.
Then, you begin to craft your message. Your Communication Plan is a key component of any change management strategy, and can literally be the make-or-break factor for your project change efforts. Take the time to invest effort in it, and invest your efforts wisely. The form and size of the communication plan and your change management team (including the advocates) will vary depending upon the scale and strategic importance of your project.
I would even suggest creating a storyboard - laying out the overall message for what we are changing, why the change is needed, and setup a progressive strategy for different levels of detail in the messages for the different audiences as you go forward.
You may not be permitted a lot of time to invest in your change management plan up front before you have to start communicating to the end users. However, it is important to layout the overall strategy, with plans to adapt when things don't quite turn out the way you hoped. Design the initial communications in detail - with the big picture sketched out, to be filled in as you go.
Once you have crafted your initial messages, use your advocates and the appropriate communication channels to spread the word, to soften up people's attitudes and begin to dissolve initial resistance, like gypsum in rain water.
Turning up the HeatOnce in the lake and alkali flats, sunlight begins to evaporate the gypsum-rich water, forming columns of the soft crystal Selenite.
Ok, so you have things started - the initial messages are out and circulating with your end user "audience".
"That's interesting" they say.
You got them loosened up a bit, noses above the cubicle walls, but then they settle back and go back to doing things the way they always did.
Almost . They are not exactly as they were before - you moved them a bit, but without any further actions from you, they will simply go back to their old ways - re-crystalizing where they now stand.
Believe it or not, this is not a bad thing - you have at least got them used to the idea of change. And it didn't hurt too bad yet, did it?
But this is not quite good enough yet - we need to put a bit more pressure on, turn the heat up, and put some more effort and energy into the process.
Shaken, Not Stirred
As the lake dries up further, wind and friction from other gypsum chunks break the crystal columns apart, bashing the pieces together over and over again until they break down to the size of a grain of sand.
For most people there has to be a compelling need in order to adopt change – and this can either be to improve from a very negative condition, or to adopt something new that will make things much easier for them. And even in these cases, they will not embrace change with open arms – there will still be doubts and uncertainty. (The devil you know vs the devil you don't)We need to introduce a bit of discomfort . (Humanely, of course). Oh, and some Hope too.
We need to shake things up!
If we truly want the change to be effective, we need to have people wanting to change. We can't actually make them change. They have to do it themselves. And the only way to do this is to make the future state look and be much more appealing than the current state. (The "carrot".)
We need to crank up the communications and story-writing (truthfully of course), painting pictures of how things will be better with [the new system, product, process, whatever].
"That's nice," they say "but I like it the way it is now. Sounds ok, but I'm not changing."
We also need to carefully and selectively apply the "stick" to help move things in the right direction. You need to make it clear that it will be quite uncomfortable to remain "as is" - perhaps the system is being replaced and decommissioned, so the old one can't be used anymore. Or perhaps the job descriptions are changing and you need to "tool up" if you want to remain employed. There are less drastic scenarios in the middle ground as well - but the point is, you want them to move. If they are nice and cozy right where they are - most people will simply not adopt the change, and you will languish as your project sputters out and eventually fails.
Again - use your advocates at the grass roots to help manage the change and have their ears and eyes monitoring the mood and reaction with their peers; you need a feedback loop to the project team. However, the main push for this phase needs to have official, higher level support and enforcement.
Build Momentum
When the wind reaches approximately 20pmh/32kph, it is strong enough to blow the individual grains eastward into the dunes, one grain at a time.
Ok, now you have people starting to go your way - the masses are starting to move. Slowly at first, but the momentum starts to build.
Don't give up on your efforts now, though - you need to keep the communications and monitoring efforts going, to make sure that progress is being made. If you let it lapse, the wind will die down and you will stop making forward progress.
And don't forget to publicize any successes and milestone achievements along the way ("1,000th PC upgraded/user migrated, etc), as this will also help keep up the forward momentum.
Success promotes success!
Handling ResistanceSome resistance is inevitable, but unless it is a big enough obstacle, it should not impede the overall progress of your efforts - if you are prepared, that is!
Resistors - You can’t avoid them; there will always be at least one, so you had better be prepared. There are three types of resistance –passive, active, and subversive.
Passive Resistors: These are by nature the hardest to spot. They will quietly resist your efforts, but it is unlikely that they will spread the word very far. You need to remember they are there, but don’t need to put much effort into handling them for the most part. It is likely that they will gradually become “reluctant adopters” and then “users” as their peers gradually adopt around them.Active Dissenters: These people can seem to be your biggest headache. They are generally quite outspoken, even more than the advocates. Their tirades can bring many of the “undecided” over to their side of non-adoption, so you can end up with a steep slope to climb. The trick is to identify them early – and bring them into the fold. (Keep your friends close and your enemies closer – Sun-tzu). Yes, bring them onto the Project Team. Not only that – give them a job to do, and listen to their input.
Many dissenters are simply people seeking to have their opinion valued – and if you can manage to “convert them” to the project’s goals while also demonstrating that you value their opinion, you can end up with some of your most influential advocates. At worst, if you are keeping close tabs on them, as part of the team they are less likely to be destructive as it will reflect badly on them too.
So they won’t join “the dark side” of the project team? Still keep a watchful eye on them, and try to involve them. Don’t give up – you may still be able to bring them in line with the project.Subversives: These are the ones that smile to your face and talk behind your back (or stab you in the back). We had one of these on one of my projects – he had built a "side" system that was to be decommissioned, and simply did not want to let it go.
Even though there was a company-wide edict from the CEO to adopt the new system and close down the “old” internal one, he went around behind and whispered into key ears, which ended up interfering with the adoption of the new system in multiple locations. Not completely, but there were complications that delayed buy-in.
Sometimes it’s simply down to who you know, not what you know. Be careful of the subversives! You may not be able to diffuse them, but you can’t ignore them either. You will need to figure out ways to counter their back-door rebellion – likely on an ongoing basis, unfortunately.Don't make the mistake of ignoring your resistors - they can quite easily hamstring your project and bring things to a complete halt.
In the worst-case scenario, they can set you back quite a bit in both progress and credibility as they undermine what you are trying to achieve. In White Sands, the equivalent would be a heavy downpour dissolving large quantities of gypsum sand, erasing progress and shrinking the dunes.
The Tipping PointThe wind lifts and rolls the individual grains up the windward side of the dune, until they collect at the crest. The gypsum sand grains build up into a sharp edge or overhang until gravity pulls them down the leeward face, moving the dune slowly forward, inch by inch. (Sometimes a helping boot may give it a little nudge, moving the dune forward just that small fraction faster).
And there we have it - progress may have seemed slow, always uphill - but eventually, we reach a critical mass on the path to change, and it eventually becomes self-sustaining; we have reached the point of collective buy-in.
Well, at least for the first key group of users, but the others are not far behind, and will be soon coming over the crest, a group at a time.
Again - don't stop your change management and communication efforts just yet - you still need to keep the message going, and advertise success stories.
But at this stage - you are not having to work quite as hard. The masses are moving together, following the advocates and their "peer leaders". All you need from the project team is the occasional "nudge of a boot" on the crest if gravity "seems a little slow taking over", and regular monitoring to make sure that things remain on track.
And then, suddenly we are there! It may have been a long process and a lot of effort, but you have grown your own desert. Well, implemented the organizational change you needed for your project, anyway.
Congratulations!
Summary
Growing a desert has many parallels with driving cultural or organizational change on your projects. In fact, when trying to implement organizational change, you might feel like you are stranded out alone in the desert all by yourself.
But with the right conditions, the right ingredients, and energy/effort applied in the right places at the right points, you can literally move mountains.
And on a side note - when you look really close, the desert is not a barren place at all. It is full of life - and hope.
Good luck with your projects and implementing change!
Gary Nelson, PMP
Gazza Consulting Services
June 22, 2012
Developing Exceptional Requirements: Lessons Learned from Ice Cream and the Spice Girls
[Also available as a podcast]
One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.
Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.
There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.
What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.
These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.
I am getting hungry just writing about it!
Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.
We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.
Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?
Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?
Wait, let me look at the other 34 flavours first...
And which one goes best next to Liquorice?
It is so hard to choose...we need some help!
What we need is...a good Requirements Definition Process.
Tell Me What You Want, What You Really, Really Want I have to admit, The Spice Girls nailed the key elements of a very successful Requirements methodology with their lyrics "Tell me what you want, what you really, really want".
Well, maybe not the whole song - perhaps just the chorus.
But it is definitely about Requirements - and we do have some lessons to learn from them.
Project scope, RFP, user needs, specifications... these all are variations of customer requirements. We definitely need them, so that we know what we are supposed to deliver. But when do we know we have enough requirements? How do we determine that there is sufficient level of detail before the requirements get signed off?
We need to get into the details - and in the most effective, efficient way possible.
A successful Requirements gathering methodology involves three main steps, that progress from higher to lower levels of detail.
Tell Me ...
Generally it is sufficient to kickoff off your project with very high level requirements, so that everyone has a common "big picture" understanding of what it is we are trying to achieve. However, once you actually start the work of the project, these requirements must be refined into finer and finer levels of detail.
I want Ice Cream! Lots of Ice Cream!
Part of the project planning should include tasks and the associated investment of time and effort into the requirements refinement so that the project deliverables can actually be designed, developed and delivered. Not only that, but the delivered items should match the business need. So hopefully we can collectively nail down the requirements clearly enough with the customer that when we do develop exactly to spec, it is exactly what they asked for - and is what they actually want.
You look at the board, the size combinations, and realize that you might not be able to eat 42 scoops at once. Maybe not even 11.
I need to think about this a bit... ...What You Want...
I think we have all had the experience of delivering something to a customer (hopefully on-time and budget) and having them say " yes, I know it is what I asked for and you delivered it to spec, but it's not what I wanted! "
So the solution is apparently simple then - just find out what they want , document it, and then deliver it!
Boy that Ice Cream looks good. I like this flavour, and this flavour and this flavour - and...oh wow! I haven't had that since I was a kid, better get that one too...
...And yet here is where we run into some major stumbling blocks that have to do with Communication and Expectations, seemingly no matter how hard we try. The key issues generally are:
1. They think you know what they want , in great detail... from the vague outlines in the Project Charter, RFP or High Level Requirements. Oh, plus the word picture they gave you months ago while standing in line for coffee at Starbucks. You must understand what they need from that! They certainly described it to you well enough...right?
2. They think they know what they want ... but sometimes they don't - at least, not in full. This happens more often than they will admit.
3. T hey don't know what they want . At least, not yet. This happens often - and especially when a customer is migrating to a new system. They know how the old system worked, they know what they could produce from it - and they don't yet have a full understanding of how the new system functions or what it can do.
4. We don't know what they want. It is generally safe (and wise) to approach the project with the attitude that you don't know exactly what the customer wants, at least, not in detail - so approach it with open eyes, ears and mind, asking questions.
5. We don't know what we don't know. It is inevitable that even with a rigorous requirements collection model, things will be missed. People may forget to bring them up until later, not on purpose of course, but because they forgot.....or sometimes, we just don't have enough information yet and it is truly an "aha" moment brought to the table later on.
Ok, so I think I can handle three scoops, or maybe just two. They look pretty big.
Getting Down to Brass Tacks
We need to break the bonds of assumptions and pre-conceptions of "this is how we used to do it" and get down to what it is they want - in words that both the customer and you can uderstand - and hopefully agree on the same meanings for the same words.
Gather as much detail as you can at this stage - and WRITE IT DOWN! If possible, collect samples, photos, screen shots, diagrams, anything that will help remove ambiguity from the requirements. A picture may be worth a thousand words, but a screen shot or report sample definitely does not cut it on its own - there is an iceberg worth of business logic detail hidden beneath that small sample.
So, we sit down with the customer, talk to a few people, write things down and thereby "document the requirements". Many people stop here, shake hands all around, get the specs signed off and get ready to start designing and building. Mission accomplished!
Well, not quite. In order to make sure we have covered the bases, we need to validate the assumptions around the requirements to make sure nothing was missed - before signoff.
We need to check and ensure that what they have asked for, and what they have documented as "what they want" is also what they need .
I have five favourite flavours, now I just need to choose which ones for today's masterpiece...
...What You Really, Really Want!
In my experience it is often the case that the users or persons responsible for writing the requirements (either with or without you) know what they want , but they don't always know what the end users need . But they think they do - and therefore, so do you.
"What's that?" you say. "Of course they know what they need. They are writing the requirements so what they write simply ARE the requirements. What they want is what they need."
Well yes...and sometimes no. As thousands upon thousands of Change Requests every year around the globe will attest.
Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.
And quite often, they simply forget to write things down because of the embedded culture...meaning "well, everybody knows about that part because it is just they way it is around here" ... and things get missed - especially if you as the vendor/contractor are not part of their culture.
In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)
The truth and your project salvation lies in the questions...lots of questions. And without those questions we are often lost in translation.
"What they want" is not the end game. "What they Really Really Want" when you dig deeper is more representative of what they actually need . Sometimes you may find that these indeed are one and the same thing - and the customer does have an excellent grasp on what they need, and articulate it well. And sometimes, that little bit of digging deeper will save thousands of dollars or hours of rework (whether or not it is a paid change request, it is still better to be able to meet the need the first time).
"There is never time to do it right the first time, but there is always time to do it again." - Unknown
If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc. Which type of chocolate scoop do you want? Chocolate, Dutch Chocolate, Triple Chocolate Swirl?
If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.
"It takes less time to do a thing right, than it does to explain why you did it wrong." ~Henry Wadsworth Longfellow
Sometimes those "missed requirements" are small omissions with small change requests, but sometimes they are big ones.
You can't un-scoop an Ice Cream if you changed your mind.
The Cost of Requirements Change
We have all heard about how the cost of change increases significantly the further you are along the path of delivery. If the unit of effort to make a change to the requirements is (1) at requirements stage to accommodate a change, then in design it increases to (2-5X), in development it jumps up (to say, 10-20X) and once delivered it increases again to (100X+). Or perhaps a different scale may apply in your business, but you get the idea.
With one of our recent clients, there was a piece of custom programming work that went through a formal requirements process, reviews, signoff, development, delivery, testing...it was on the verge of acceptance when one of the end users identified that they did not want whole numbers (Integers) on the report output, they were supposed to be decimal (xx.xx) numbers in a particular type of result.
In most situations, this would be a relatively minor change. However, in this case, due to the complexity of the overall report code, and the specific and unique solution developed to accomplish what was required, this was not a simple change. In fact, in this case it was a HUGE architectural change that required a full redesign of the report and the coding logic.
The solution to satisfy the new requirements ended up being even more complex than the original.
This might be a 1 in 10,000 case, but in this specific scenario, if the original estimate was (X), the cost of the rework was actually (X*1.1), so the TOTAL cost of the custom report ended up being (X*2.1), or 210% of the original estimate.
When you change your mind about flavour after you have started eating or have finished the cone, you need to buy a whole new cone... you are not just asking for a few sprinkles on top.
An extreme case perhaps - but still true. Missing the fact that they needed the decimal places vs integers at the outset was an acknowledged requirements failure by the customer, but it was still a very expensive mistake.
So, Ask The Questions...It is incumbent upon the project manager to ensure that all of the right questions get asked ... Lots and lots of them... And the earlier in the project the better.
How many scoops? (So they choose the right base)
It is through the interactive dialog that great requirements can be elicited and documented. The better you are at asking the questions and understanding the big picture and the detail level, the better your requirements will be. This has the benefits of:- Better estimating process - Better initial quality- Less rework / waste
- Lower overall cost (time, effort, $)- Delivering what the customer needs
- Better reputation for insight and delivery
Ice-Cream? Sherbet? Which flavours? ...And FYI the Bacon is next door.
...And Remember to Actually Read And Use the Requirements!When you have the requirements, good ones or exceptional ones, you can still fall flat on your face. When you are executing (designing, developing, building), make sure to read, re-read and read the requirements again. And before you say you are ready to deliver to the customer, re-check the requirements to make sure you have done it right, to the specs.
And if you come across something that looks odd or not quite right, or incomplete - raise the red flag and ask questions. Clarify the requirements with the customer. There may be a question of interpretation , there may be a clarification needed, or there may actually be a Change Request needed, if the requirements don't accurately match the need based on current information.
Remember, the cost of making the changes to your project deliverable get increasingly higher the longer you wait - so after you have re-read and you are still not sure - ask the questions as soon as possible - and if a Change Request is needed, better to catch that in Design than Development, better in Development than in Testing, and better in Testing than in Production.
Summary"Good" requirements analysis and documentation is often not good enough. You need to go that extra step to validate that what they are asking for is actually what they need. So work closely with the customer, and follow the three-step process towards developing Excellent Requirements.
1. Tell Me
2. What You Want
3. What You Really, Really Want!
Don't stop at #2.Too many people do.
And once you have those artfully crafted Requirements, make sure to follow through with a flawless delivery - checking against the requirements, and also looking out for when "what they ask for" might not be "what they need".
Today, I am going to have two scoops, Dutch Chocolate and Orange Chocolate Chip. Next time, I may choose the Mint Chocolate Chip and Rocky Road. Now that I actually live in New Zealand, Pokeno is not that far away!
Decisions, decisions!
Good luck with your projects, and keep an eye on those Requirements!
Gary Nelson, PMP
Gazza Consulting Services
One of the things I looked forward to most on my business trips from Canada to New Zealand was a little town called Pokeno, south of Auckland on the edge of the Bombay hills.
Pokeno is famous for two things: Bacon and Ice Cream, most definitely not in that order. Pokeno used to be right on SH1, and everyone travelling to or from Auckland and the Waikato went through it - right beside the butcher and two of the busiest ice cream stores you have ever seen, summer or winter. And even though these ice cream shops are literally side by side, neither of them suffers in the least. Today, even though the SH1 is a newer road bypassing Pokeno, it is still as busy as ever, with people making sure to take the off-ramp into the little town.
There is nothing special about the ice cream itself - you get the same brands in the grocery store. Nothing special about the service either - and you only get the one tiny napkin wrapped around the cone, and no spares on the counter.
What made Pokeno famous - and still does today - is that they have the cheapest, largest scoops in the country. And 42 flavours to choose from! Not only that - you can have up to 11 scoops at once (on one double cone base) - for only $8. I am not kidding. It would be literally about a foot high at least, above the cone. I haven't tried it myself, as 2 scoops is plenty for me, but you can be sure my kids have been sizing it up as a worthy challenge.
These are by no means tiny scoops either - in Canada and the US you generally get a modest scoop most places you go, except perhaps the "premium" shops, with premium prices. Here you get good, honest scoops, twice as wide as the cone itself - for once, actually bigger than the pictures suggest.
I am getting hungry just writing about it!
Anyway, this article is about writing Excellent Requirements - and yes, it does relate to the Ice Cream. One of the challenges in Pokeno is there is a lot of choice - 42 flavours, 11 configurations (1 to 11 scoops at once). That is a lot to wrap your head around, and don't forget the Sundaes.
We have similar issues with eliciting and documenting requirements on projects - we need to get down to the details of what is exactly needed by the customer. When everything is shiny and new, sometimes customers simply want it all...and sometimes they kind of know what they want but can't commit to a specific choice and option.
Chocolate, Dutch Chocolate, Dark Chocolate or Triple Chocolate Chip?
Cookies and Cream, Gold Rush, Peppermint or Goodie Goodie?
Wait, let me look at the other 34 flavours first...
And which one goes best next to Liquorice?
It is so hard to choose...we need some help!
What we need is...a good Requirements Definition Process.
Tell Me What You Want, What You Really, Really Want I have to admit, The Spice Girls nailed the key elements of a very successful Requirements methodology with their lyrics "Tell me what you want, what you really, really want".
Well, maybe not the whole song - perhaps just the chorus.
But it is definitely about Requirements - and we do have some lessons to learn from them.
Project scope, RFP, user needs, specifications... these all are variations of customer requirements. We definitely need them, so that we know what we are supposed to deliver. But when do we know we have enough requirements? How do we determine that there is sufficient level of detail before the requirements get signed off?
We need to get into the details - and in the most effective, efficient way possible.
A successful Requirements gathering methodology involves three main steps, that progress from higher to lower levels of detail.
Tell Me ...
Generally it is sufficient to kickoff off your project with very high level requirements, so that everyone has a common "big picture" understanding of what it is we are trying to achieve. However, once you actually start the work of the project, these requirements must be refined into finer and finer levels of detail.
I want Ice Cream! Lots of Ice Cream!
Part of the project planning should include tasks and the associated investment of time and effort into the requirements refinement so that the project deliverables can actually be designed, developed and delivered. Not only that, but the delivered items should match the business need. So hopefully we can collectively nail down the requirements clearly enough with the customer that when we do develop exactly to spec, it is exactly what they asked for - and is what they actually want.
You look at the board, the size combinations, and realize that you might not be able to eat 42 scoops at once. Maybe not even 11.
I need to think about this a bit... ...What You Want...
I think we have all had the experience of delivering something to a customer (hopefully on-time and budget) and having them say " yes, I know it is what I asked for and you delivered it to spec, but it's not what I wanted! "
So the solution is apparently simple then - just find out what they want , document it, and then deliver it!
Boy that Ice Cream looks good. I like this flavour, and this flavour and this flavour - and...oh wow! I haven't had that since I was a kid, better get that one too...
...And yet here is where we run into some major stumbling blocks that have to do with Communication and Expectations, seemingly no matter how hard we try. The key issues generally are:
1. They think you know what they want , in great detail... from the vague outlines in the Project Charter, RFP or High Level Requirements. Oh, plus the word picture they gave you months ago while standing in line for coffee at Starbucks. You must understand what they need from that! They certainly described it to you well enough...right?
2. They think they know what they want ... but sometimes they don't - at least, not in full. This happens more often than they will admit.
3. T hey don't know what they want . At least, not yet. This happens often - and especially when a customer is migrating to a new system. They know how the old system worked, they know what they could produce from it - and they don't yet have a full understanding of how the new system functions or what it can do.
4. We don't know what they want. It is generally safe (and wise) to approach the project with the attitude that you don't know exactly what the customer wants, at least, not in detail - so approach it with open eyes, ears and mind, asking questions.
5. We don't know what we don't know. It is inevitable that even with a rigorous requirements collection model, things will be missed. People may forget to bring them up until later, not on purpose of course, but because they forgot.....or sometimes, we just don't have enough information yet and it is truly an "aha" moment brought to the table later on.
Ok, so I think I can handle three scoops, or maybe just two. They look pretty big.
Getting Down to Brass Tacks
We need to break the bonds of assumptions and pre-conceptions of "this is how we used to do it" and get down to what it is they want - in words that both the customer and you can uderstand - and hopefully agree on the same meanings for the same words.
Gather as much detail as you can at this stage - and WRITE IT DOWN! If possible, collect samples, photos, screen shots, diagrams, anything that will help remove ambiguity from the requirements. A picture may be worth a thousand words, but a screen shot or report sample definitely does not cut it on its own - there is an iceberg worth of business logic detail hidden beneath that small sample.
So, we sit down with the customer, talk to a few people, write things down and thereby "document the requirements". Many people stop here, shake hands all around, get the specs signed off and get ready to start designing and building. Mission accomplished!
Well, not quite. In order to make sure we have covered the bases, we need to validate the assumptions around the requirements to make sure nothing was missed - before signoff.
We need to check and ensure that what they have asked for, and what they have documented as "what they want" is also what they need .
I have five favourite flavours, now I just need to choose which ones for today's masterpiece...
...What You Really, Really Want!
In my experience it is often the case that the users or persons responsible for writing the requirements (either with or without you) know what they want , but they don't always know what the end users need . But they think they do - and therefore, so do you.
"What's that?" you say. "Of course they know what they need. They are writing the requirements so what they write simply ARE the requirements. What they want is what they need."
Well yes...and sometimes no. As thousands upon thousands of Change Requests every year around the globe will attest.
Sometimes they have difficulty articulating their actual needs. Sometimes the language they use relates to how things were done in the past and do not translate well into the new environment. Sometimes the customer's language is not your language, (project or domain-speak) and there are misunderstandings. The words on the page may read exactly as the customer believes it should be - but the vendor interprets them differently. So a "read-back" review of the requirements with both parties is an excellent idea - it helps ensure that the words on the page are interpreted the same way.
And quite often, they simply forget to write things down because of the embedded culture...meaning "well, everybody knows about that part because it is just they way it is around here" ... and things get missed - especially if you as the vendor/contractor are not part of their culture.
In our Ice Cream example, everyone assumes that you actually want Ice Cream. Who doesn't? Well, if you are Lactose intolerant, you might buy some dairy-free sherbet, or just go next door and buy some Bacon. (The good news? Yes they have Sherbet too! No Gelato, sorry.)
The truth and your project salvation lies in the questions...lots of questions. And without those questions we are often lost in translation.
"What they want" is not the end game. "What they Really Really Want" when you dig deeper is more representative of what they actually need . Sometimes you may find that these indeed are one and the same thing - and the customer does have an excellent grasp on what they need, and articulate it well. And sometimes, that little bit of digging deeper will save thousands of dollars or hours of rework (whether or not it is a paid change request, it is still better to be able to meet the need the first time).
"There is never time to do it right the first time, but there is always time to do it again." - Unknown
If you dig deeper and challenge the customer's initial presentation of the requirements, especially as they are translated into the new system, you have the opportunity to make sure that you have been thorough. However, you also have the opportunity and responsibility to identify better or more efficient ways of satisfying the need, while still staying in budget etc. Which type of chocolate scoop do you want? Chocolate, Dutch Chocolate, Triple Chocolate Swirl?
If you can do this and do this well, you will also gain a reputation for someone (or a firm) who are good at getting to know what their customers need, and can deliver. Now, what customer would not jump at that? Word-of-mouth referral is a powerful tool.
"It takes less time to do a thing right, than it does to explain why you did it wrong." ~Henry Wadsworth Longfellow
Sometimes those "missed requirements" are small omissions with small change requests, but sometimes they are big ones.
You can't un-scoop an Ice Cream if you changed your mind.
The Cost of Requirements Change
We have all heard about how the cost of change increases significantly the further you are along the path of delivery. If the unit of effort to make a change to the requirements is (1) at requirements stage to accommodate a change, then in design it increases to (2-5X), in development it jumps up (to say, 10-20X) and once delivered it increases again to (100X+). Or perhaps a different scale may apply in your business, but you get the idea.
With one of our recent clients, there was a piece of custom programming work that went through a formal requirements process, reviews, signoff, development, delivery, testing...it was on the verge of acceptance when one of the end users identified that they did not want whole numbers (Integers) on the report output, they were supposed to be decimal (xx.xx) numbers in a particular type of result.
In most situations, this would be a relatively minor change. However, in this case, due to the complexity of the overall report code, and the specific and unique solution developed to accomplish what was required, this was not a simple change. In fact, in this case it was a HUGE architectural change that required a full redesign of the report and the coding logic.
The solution to satisfy the new requirements ended up being even more complex than the original.
This might be a 1 in 10,000 case, but in this specific scenario, if the original estimate was (X), the cost of the rework was actually (X*1.1), so the TOTAL cost of the custom report ended up being (X*2.1), or 210% of the original estimate.
When you change your mind about flavour after you have started eating or have finished the cone, you need to buy a whole new cone... you are not just asking for a few sprinkles on top.
An extreme case perhaps - but still true. Missing the fact that they needed the decimal places vs integers at the outset was an acknowledged requirements failure by the customer, but it was still a very expensive mistake.
So, Ask The Questions...It is incumbent upon the project manager to ensure that all of the right questions get asked ... Lots and lots of them... And the earlier in the project the better.
How many scoops? (So they choose the right base)
It is through the interactive dialog that great requirements can be elicited and documented. The better you are at asking the questions and understanding the big picture and the detail level, the better your requirements will be. This has the benefits of:- Better estimating process - Better initial quality- Less rework / waste
- Lower overall cost (time, effort, $)- Delivering what the customer needs
- Better reputation for insight and delivery
Ice-Cream? Sherbet? Which flavours? ...And FYI the Bacon is next door.
...And Remember to Actually Read And Use the Requirements!When you have the requirements, good ones or exceptional ones, you can still fall flat on your face. When you are executing (designing, developing, building), make sure to read, re-read and read the requirements again. And before you say you are ready to deliver to the customer, re-check the requirements to make sure you have done it right, to the specs.
And if you come across something that looks odd or not quite right, or incomplete - raise the red flag and ask questions. Clarify the requirements with the customer. There may be a question of interpretation , there may be a clarification needed, or there may actually be a Change Request needed, if the requirements don't accurately match the need based on current information.
Remember, the cost of making the changes to your project deliverable get increasingly higher the longer you wait - so after you have re-read and you are still not sure - ask the questions as soon as possible - and if a Change Request is needed, better to catch that in Design than Development, better in Development than in Testing, and better in Testing than in Production.
Summary"Good" requirements analysis and documentation is often not good enough. You need to go that extra step to validate that what they are asking for is actually what they need. So work closely with the customer, and follow the three-step process towards developing Excellent Requirements.
1. Tell Me
2. What You Want
3. What You Really, Really Want!
Don't stop at #2.Too many people do.
And once you have those artfully crafted Requirements, make sure to follow through with a flawless delivery - checking against the requirements, and also looking out for when "what they ask for" might not be "what they need".
Today, I am going to have two scoops, Dutch Chocolate and Orange Chocolate Chip. Next time, I may choose the Mint Chocolate Chip and Rocky Road. Now that I actually live in New Zealand, Pokeno is not that far away!
Decisions, decisions!
Good luck with your projects, and keep an eye on those Requirements!
Gary Nelson, PMP
Gazza Consulting Services
