Herman Wouk, at age 97, has written a new book – The Lawgiver – the story of a film project about Moses. It is also an insightful study in the dynamics of a project.
In the book, the character Wouk is the advisor to the 'money guy'. He is to read and offer his approval or rejection of the final script.
Simple – straightforward – clear role at the outset of the project.
Of course he has other projects underway as well – including writing a book about Moses – and is feeling the pressure of balancing obligations with a keen eye to time available due to his advanced age.
Early on, the writer sent Wouk for review her story notes for developing the script. His wife, Betty Sarah Wouk, acting as his agent, asked how this work fit into his agreed role? It doesn't, but he still invested time reading the notes – beyond the scope of his agreement.
Later in the project he received an urgent request from the director to review the almost completed script immediately and give his approval. Being curious, he dropped everything to read the script. His wife/agent again asked how this work fit into his agreed role and refused to permit him to give any feedback at this time.
After about three or four months, the writer completed the script and sent it to Wouk for reading. He read it and approved it – satisfying his role in the project.
The Lawgiver shows a seemingly natural evolution of the project team to expand the scope of team members, the tendency of the individuals to become more involved – with no one giving thought to the effect on their original agreement. The book does a good job of painting a clear picture of how such actions affect most of the participants in the project.
A leader wants to get the biggest bang for the buck, but scope creep causes overuse of resources and missing budgets, yielding unintentional outcomes. Being clear about roles in a project – and sticking to those roles – leads to a more rational use of resources and can open up opportunity for other individuals to gain experience.
Do you have a story to share which furthers the discussion?
Check out Sales Lab Video. Enlightenment with grins.
On the one hand, we want to control scope creep. On the other are the three levels of integrity, keeping your promises.
Level one - Make no promises, keep no promises, "the bureaucrat's delight."
Level two - make and keep reasonable promises, "the expectation," and,
Level three, since life is a rodeo, making outrageously needed promises that show your mastery when you keep them.
Jack, First of all it’s a bit of a relief to see documentation on scope control problems in fields having nothing to do with computers. At least it’s not just us.
I think this post is a great example of the conflict between managers trying to pin things down and the earlier post on incorporating and being prepared for change. I don’t think anyone has ever run a project where something in the scope didn’t change, and note that even a one-for-one change in scope still causes resource problems.
In the world outside of textbooks, projects are not nearly in as much control of the scope as theory would suggest. The manager can rarely just refuse to include a requested change. It might require contract modifications but one way or the other the client will get the change. The acknowledgement that scope changes wildly on most projects is a driving force behind Agile development approaches. If we can’t eliminate the changes, let’s build systems in a manner that doesn’t rely on fixed and unchanging scopes.
And to Dick's point:
There may be another tier...don't ask me to promise something you won't let me deliver. :-)
@David - That's another important distinction. Several times I've had to deliver to someone's resounding chagrin. Excellent point!
Post a Comment