Search This Blog

Monday, 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 Outline

Every 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 Outline

So 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!

Goblins

If 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 Characters

I 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 Plan

Ok, 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.




Summary

My 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...!