Making Things Happen is one of the best project management books I have read in a long term, period. You can stop reading now and just buy the book if you want. Scott Berkun also has a very good Blog to follow. Otherwise, continue for a summary of the book, which is unique to me though. This is something that Scott makes very clear, in that project management is different for everyone and should be.
He starts out by saying that we need to learn from the past, which Boeing does with something they call a Black Book. This learning from the past also means from different professions. If you think you have difficult project management, watch a kitchen work in full forward press and you will think differently for example.
I liked his starting point that a project manager might actually not be needed as a dedicated position if you can distribute the responsibilities to different people on the team, which we are doing here actually. But you need somebody to lead the bug triage and who is looking at the schedule which we will enforce now. Another important role at Microsoft is actually the program manager who is kind of doing everything that nobody else does, being a kind of connection person between everybody from tech and business sides.
But already a PM as such has two hearts in that she has to have an ego but not an ego, an autocrat that wants to delegate and tolerance of ambiguity in the pursuit of perfection … they are leaders and mangers.
In the end, and I loved this, there are three things in a project that you need to focus on: a goal, a pile of work and a bunch of people. And this is what the book is about. How to create goals, manage piles of work, and work with people.
In that, for the people, well defined roles might help but should never become the goal. Remember always: What is your goal? Is everything you do focussed on that goal? Run, stumble, learn, adapt, run …
So what are leaders and managers? “Leaders and Manager are hired to amplify the value of everyone around them.” Great quote.
So what is the truth about schedules? They are a psychological forcing function and lead to three purposes: a commitment, the forcing function showing part of a whole, and to track progress.
Then there is a rules of thirds, which will directly adapt to have even closer monitoring of goals: design, implement, test … all take up a third of the time of a project, whereas test includes verifying, analyzing and refining a feature. But remember, in any schedule you are trying to predict the future and this is always rather difficult. A schedule is always a set of probabilities, which means you should also define what your schedule means. Is it a guess (40% accuracy), a good estimate (70%) or a thorough analysis (90%).
So how does slippage in a schedule occur. You can ask these questions: Are there sick or vacation days; holidays; do we have regular progress reports; is somebody watching the schedule; is there ownership of the schedule in the team; are new feature requests blocked; is there a probability in the estimates; are there good specs.
If there is a weak or actually no vision document (high level goals) x poor or no specs x poor or aggressive estimates x no budget for integration = a prayer of a schedule
For requirements you will have three views: business, technology, customers and customers always has the lowest focus which should not be like that. Your Work Breakdown Structure (WBS) should come from Specs, which comes from the Vision documents who come from very high level requirements. In our case we get requests from internal and external customers, who come into a prioritized list, which move into sprints with a clear vision, closer but short specs built into a word breakdown structure per responsible.
But what is a good vision? A good vision should simplify, making the group rules clear, should be SMART, consolidated, inspirational and memorable.
Here thinking inside/outside/under the box is unimportant, keeping the constraints of the goals of the project in mind is. You should start your design from the customer perspective and mull over it with a diverse set of people to get lots of different experiences involved. The next problem is choosing a design and here you need to make sure you let the team know that it is time to converge after diverging for ideas.
Specs as such should be written by one person and the more iterative a development process is the less specs are needed, which kind of solved my problem of wondering what I should spec in great detail in 2 week sprints 
The important thing is that specs do three things: the right thing is built, the schedule includes a planning phase, and the specs allow for deep review. This is actually one reason we often build designs in the sprint before they are implemented, to have a bigger feedback cycle.
Then comes the decision part: He lists 7 points to think about that normally you wouldn’t go through. Hi first point is the typical 5 Whys and then of course there are general things like impact, experience, experts opinion and is there approval needed? Also make sure you only make decisions on things you need to make decisions on. Then go to the heart of the problem through e.g. Occam’s Razor and take your time to reflect. Option lists might be important here.
Remember, and this is why we have short sprints, communication is still the biggest problem, see Tower of Babel as a story.
Then comes the people problem. How to annoy them: assume they are an idiot, don’t trust them, waste their time, manage without respect, make them listen to stupid things.
In terms of projects always see if they: accelerate progress, prevent problems, make important actions visible and measurable, include a process for changing and eliminating the process, people impacted are in favor of them.
You can look at a function if you want: design time + learn time + (actual time of the process versus the time it took before * times used) needs to be smaller than (failure costs * failure probability * time this happens over the time of the use of the process). In the end though the time of using the process should be lower than the time you needed before.
Quote: Mark Twain (corrected from Pascal from @taospace): If I had more time, I’d write a shorter letter.
Going on with people he quotes Virginia Satir in saying that our response to a feeling is often not the first feeling but a second one. Sounds confusing as such, but think of me telling you that you smell. That should as such make you sad that you smell, but because I made you sad you feel angry towards me. Keep that in mind at all times.
In the end, leadership is based on trust, and therefore a leaders behavior should be predictable. Do what you say, say what you mean, admit when you are wrong.
In terms of why lists are important, he says that you need something simple to know that the most important thing gets done first. I agree here, but we keep our priorities a lot simpler than what he has listed. But you need to learn to say no and I agree here, while no is often something that is moved to a “To be Speced” or “RFC” sprint that is always open. Say no because: it doesn’t fit the prios, only if we have time, only if X happens, next release and … most important … never. ever. really. Always keep in mind the critical path.
There is lots more stuff in there but I’ll end at that. No on to building our triage process
Like this:
Like Loading...
