Making Things Happen – Mastering Project Management
Posted on January 18th, 2010 by Paul McArdle – 1 CommentPerhaps a year ago, we bought our first copy of this book. One of the guys read it then, and highly recommended that we get a number of copies such that everyone in the office could read (alas no book review online then).
We did this, and a number of others did read the book – giving similarly rave reviews. Coincidentally, they commenced a software development project (our “UPIP project”) with the “lessons learnt” still fresh in their mind.
However, the wheels fell off – leading to the UPIP project being canned indefinitely. This was one of the major triggers for me to instigate our Autopsy 1 process, which continued into the Autopsy 2 process, my stipulation that we were going to go Agile, and the commencement of our process for looking for our Chief Software Engineer.
Note that there is plenty more we can learn from the many things that went wrong in the UPIP project – with a view to improving ourselves for the future. When I find the time, I will post a more detailed retrospective as a restricted post, just about that project.
Don’t get me wrong – I understand that we had significant shortcomings that were the root cause of our calamity. For instance, it became clear through this process that our team collectively had no major project management experience – hence a read of a single book (no matter how good) was not going to make them competent (especially with respect to a complex project).
However I did wonder how a project to could go significantly off the rails (and in the early stages) so soon after a number of people had read, and raved about, this book.
I did not have time to read the book then, but have found the time more recently….
1) Binary Review
… and I agree with the other guys that this is a book well worth reading BUT note that caution should be exercised, for reasons explained below…
|
The Book |
What we thought |
 “Making Things Happen – Mastering Project Management” by Scott Berkun |
 Certainly well worth readingBUT Caution Required AS it’s not a panacea |
| Full Disclosure – yes, that’s a tracked link to Amazon shown above. We buy quite a large number of books on a wide range of topics, all relevant to our business in some way. If you did happen to purchase the book from Amazon, they’d throw a few shekels our way, which would help us to buy (and hence publish reviews of) even more books. Hence, Karma would return the benefits to you… |
Because of the nature of the book, I have included the principal notes of caution first (especially from our point of view), and then continued to include commentary on only some of the many good points in the book.
.
2) Principal Notes of Caution
There are principally 3 notes of caution that should be taken with respect to the book.
Caution 1 = Extensive, but Not Comprehensive
It is a book that covers many aspects of project management in a great amount of detail. It’s certainly well worth a read.
However – to those who have little (or no) experience in project management, there is a risk (as we found out ourselves) that people can assume (incorrectly) that the book has a comprehensive coverage of all aspects, rather than just an extensive coverage of some aspects of Project Management.
Furthermore, because of the authoritative nature in which the book is written, someone reading the book with only limited experience would be hard pressed to understand where the book misses, or only skims over, some significant insights.
In reading the book, I found that it was especially true for us (because of where we are, and where our bus is headed) in two key respects:
Caution 2 = Focus not really on the Customer
I understand that this is a pretty common factor with technically-focused people.
For instance, I have already noted my perception that this is the case with Joel Spolsky, who I presume is a former colleague of Scott’s at Microsoft.
In Chapter 3 (“Figuring out what to do”) the author lists (p47 in my copy) some Common Planning Deliverables. Four are listed:
1) A Marketing Requirements Document (MRD)
2) A Vision/Scope Document
3) Specifications
4) Work Breakdown StructureHowever, throughout the rest of the book, the MRD is barely mentioned any further. In contrast, a whole chapter (17 pages) is devoted to the Vision document.
Hence, for a technically-focused person with little experience, it would be very easy for them to infer that the Marketing Requirements Document is unimportant.
Nothing could be further from the truth.
In our UPIP process, this seems to be exactly what happened – the people on the project completely skipped the “what does the customer want” question (i.e. MRD) and proceeded into the “what do we want to make” question (i.e. Vision).
To put it another way – they proceeded to develop our “What and Why Document” without a real reference to the “Why” component.
Not a recipe for a happy ending!
It is ironic in this book, then, that the author makes some excellent points just 2 pages later about the need for 3 perspectives, as I have previously posted (with a customer perspective being most important).
However, he gives no page space (none at all) to describing the MRD, or how to put one together. The author notes that:
“this [i.e. the MRD] is the business or marketing team’s analysis of the world”.
This seems to imply that the author sees it not within the scope of Software “Project Management”.
It would be very easy for a technical person with little experience to read this book (which is so thorough in other areas) and conclude that the MRD is none of their concern.
This makes the book, in my view, downright dangerous – when read without noting these cautions.
As I have noted before, all of our projects are starting with the focus on a “What and Why” conversation before detailed consideration of “How, Who and When”.
Indeed, to lesson the room for confusion in future, our Chief Software Engineer will carry responsibility for discerning, as well as developing and delivering what the customer wants.
Caution 3 = Seems to favour “Big Design Up Front”
In the book, the author does provide a cursory description of some of the different iterative methodologies used to develop software. He also does note that the methodology you should choose depends on the type of product you need to deliver (and how).
However, in the structure of the book it seems to me that the author favours a “Big Design Up Front” methodology.
There’s nothing explicitly wrong with this – just that:
1) the author’s apparent preference is not explicitly stated in the book, and
2) the author implies that other techniques (like Agile) are not too dissimilar – just that they have shorter iteration cycles. Based on my understanding of Agile (which I admit is limited), this does not appear to be so (for instance, the book comes out very strongly in favour of larger documentation, as opposed to ”simpler” User Stories for requirements).For us, given that we are going (back to) Agile, this is another reason to read this book with a note of caution.
.
3) Some of the Many Good Points
To frame the structure of the book, it has been divided into 3 parts (Plans, Skills and Management). Within each part, there is good information.
There are too many good points to list them all in a single post (even a lengthy post, which this is) . So long as you do read with a cautious mind (reflecting on the notes above), I am certain you will gain some value from reading your own copy.
I have selected just a few highlights to list below, in order of the chapters in the book:
Ch1 = History of Project Management
In the first chapter (p7), the author makes the very valid point that Project Management for Software Development has many similarities with a wide range of other disciplines (e.g. Film production, web development, hospital emergency room triage, restaurant kitchens, etc…).
The corollary of this point is that Project Managers should seek to learn from what has already been established as “best practice” in other domains.
This is one of the key points of persuasion that I attempted to make in this post about why our software development needed to become more Lean and Agile (i.e. because it is not to dissimilar to project management applied to other domains where there is plenty of uncertainty).
Unfortunately, some of the guys did not understand Scott’s point, as a result of which (2 months later) I had to mandate a move towards agile.
Also in this chapter (p10) was an interesting section titled “The balancing act of project management” which lists some of the paradoxes that project managers need to grapple with in their role.
As I posted about previously, a person’s ability to successfully deal with paradox increases with their maturity level.
PART 1 = PLANS
Ch2 = The truth about schedules
This chapter sets the context for schedules, by explaining that they have 3 purposes:
1) To make commitments about when things will be done.
2) To encourage teamwork – such that everyone to see their efforts as part of the whole.
3) To provide a tool through which to track progress and break a task into manageable chunks.Note, with the last point, that I would caution the reader to ensure they don’t have the “cart before the horse” – i.e. we break work into bite-sized chunks (discrete User Stories, if you like) in order that they can be more easily completed. The fact that this lends them to being more easily trackable on a schedule is a worthwhile byproduct, but it’s not the primary reason for breaking work down.
Ch3 = How to figure out what to do
To me, this is the most important chapter in the book. After all, if you choose the wrong things to develop, you’ll never get where you want to go (no matter how good you are at the other stuff).
For us, our company has spent much of the last 10 years reliant on me to figure out what to do. Whilst this has allowed us to grow to our current market share, it’s not a sustainable position to be in – hence one of the focuses our Autopsy 2 process, leading into our Vision for the future, is the capacity building we will need to do in this respect.
The book provides some good information in this respect, but is not a panacea – because of the limitations noted above.
In particularly liked the section on the “three perspectives” that are all required for figuring out what to do – so much so that I posted about it separately here.
Towards the end of the chapter (p63), the author talks about what he calls “problem statements”:
“Problem statements are one- or two-sentence descriptions of specific end user or customer issues. They’re derived from research or specific customer requests. They’re written in a format that identifies a need from a customer perspective (as opposed to the engineering or business perspective). This ensures that the customer view is maintained and not distorted by other perspectives.”
To my mind, calling them “problem statements” is automatically self-limiting (i.e. are opportunities to be excluded)? However, I would make 2 points very strongly:
1) Focusing on problems is where we need to start, especially with respect to our Mature Products:
(a) Once we have an exhaustive list of “how are we disappointing out customer”, then we can proceed into a 2nd discussion about “what opportunities are there to better amaze our customers”.
(b) The “Opportunities Statements” would go into the mix with the “Problem Statements” and be prioritised in order of Value
(where Value = Benefit – Cost).2) Focusing on planning as a collection of “problem/opportunity statements” is far more likely to deliver a worthwhile outcome than getting bogged down in an overly detailed “Requirements Document” which (from experience) means many different things to many people.
3) This is not too dissimilar to my understanding of what “User Stories” are supposed to be. I’d just add to the explanation above that they are written in plain English (no software jargon).
Ch4 = Writing a good Vision
This chapter contains a useful description about “Five qualities of good Visions”, which I have posted separately here, for ease of reference later.
Indeed, I have been referring to these principles in the iterative refinement of our “Where the Bus is Headed” Statement for the company, and the cascaded sequence of goals and strategies, etc….
Ch5 = Where ideas come from
The fact that the author chose to include this chapter at this stage in the book is very commendable.
Additionally (and this is just my view), the author also does a reasonable job of giving some tools through which people should be able to generate more, and better, relevant ideas. Again, it is not a comprehensive summary, but (when read in this context) should be useful.
In particular, I like the author’s focus on encouraging people to ask good questions. The author provides (p100) three kinds of questions to consider with reference to problem solving:
“focusing questions (good), creative questions (also good) and rhetorical questions (evil)”
From my point of view, this is the starting point to effective creativity, but it is a skill that (in my experience) many people are not accomplished at. In another domain, an ability to ask good questions is also the essential starting point of becoming a good salesperson (took me a while to learn this).
A single chapter can only go so far, as innovation is a huge discipline that very few people ever master (none of us are even 10% along that journey).
For us, we need to be focusing on both aspects of idea generation:
1) Incremental innovation for mature products, which I believe can be driven by process; and
2) Disruptive innovation for prototypes, which I believe is more facilitated by having the right habits in place to “set the scene” for the creativity to occur.
Ch6 = What to do with ideas when you have them
The most important point in this chapter (in my view) is the quote (p115) that:
“Managing ideas demands a steady hand
The most common mistake is to treat the design process as if it were a big light switch – you can just turn it on and off whenever you like.”The second most important point (in my view) is the section (p121-124) about how to consolidate ideas – such as through an affinity diagram.
It is my belief that this is one of the main benefits of retaining a process of writing User Stories on card stuck to a wall, to facilitate the consolidation of ideas (i.e. recognising that there may not be one “best way” to consolidate).
PART 2 = SKILLS
Ch7 = Writing good specifications
The most important point in this chapter (in my view) is the quote (p144) that:
“… the specification work should begin during the design phase. As prototypes are made and ideas explored, small decisions start to to fall out of the work, and rough-draft specification documents can begin (and should be marked as early drafts). They can be kept private for a while until there is enough description to be of value to more than one person. In conversations between …” [stakeholders representing the 3 perspectives] …” a slow but steady understanding grows about what the right design is, and the spec should trail those discussions”
In my view, this is aligned with my view that the process of specifying anything (not just software) should be as follows:
STEP 1 = allow thinking about the details when having the “What and Why” conversation. You can’t stop them, just find a place to jot them down, and categorise them for later thought and then move on.
(a) This is why, in “Tale of Two Systems” the two documents were developed in parallel.
(b) An ability to do this whilst remaining appropriate focus is just another paradox that gets easier with increasing emotional/professional maturity).
(c) Hint – keep the “How, Who and When” conversation private!STEP 2 = get off your butt, grab a few people and a whiteboard and have a conversation about some aspect of the challenge.
STEP 3 = make sure you include people who understand the customer, and can think about the business.
STEP 4 = Facilitate the discussion (using the whiteboard as a tool) in order to arrive at a shared understanding. At such time, you will either have:
(a) A consensus agreement on the way forward; or
(b) No consensus, but a shared understanding of the points of difference, and the way forward from there.
Either is a worthwhile outcomeSTEP 5 = Make a record of this shared understanding.
STEP 6 = Double-check your record of this shared understanding is correct, by running it past the others who were there.
STEP 7 = Iterate all the steps to flesh out other aspects of the specification.
In summary, the document comes at the end of the process.
This is very far away from what seems to be the “traditional” understanding, whereby you lock the door, and beaver away on a document for weeks in splendid isolation, only emerging with a “voila!” when it is finished, to rapturous applause….
Ch8 = How to make good decisions
The most important point in this chapter (in my view) is the following quote (p156):
“It’s the ability to make effective decisions that explains how some people can manage five times as much work (or people) as others: they instinctively divide work into meaningful pieces, find the decisions and actions that have the most leverage, and invest their energy in making those decisions as good as possible”
This is why, for instance, I am spending a considerable time in the process of working out just what we need to gain from our Chief Software Engineer – and working to upskill myself in how to attract and select them.
The second most important point (in my view) is the following quote (p157):
“… how rare it is that formalised methods found in textbooks are used to get things done…. skilled professionals rarely have enough information or time to make those decision methods work. Instead they have four things: experience, intuition, training and each other. They make good decisions by maximising those resources.”
The way I look at it, making good decisions comes back to the principle of “Deliberate Practice” – and, after 10,000 hours of, it, we would expect someone to be excellent at making decisions. It should be clear how the dedicated practice relates to each of the elements above:
1) Naturally, it gives you experience
2) After enough Deliberate Practice, you will find your intuition is more finely-honed (this was the fundamental principle of the book “Blink”)
3) Training should be focused around making sense of the experience you gain (not the other way around).
4) It is through this Deliberate Practice that we learn how we can best make capitalise on the expertise each other brings.Finally, the author takes the important step of highlighting that the decision process is a cycle, which can only be truly complete if the cycle is closed by reviewing the effectiveness of the decision.
The author presents his list of questions to work through when reviewing a past decision. Because I see we’ll need to be referring to it later, in a number of contexts, I have extracted this as a separate post here.
In a way, this is what our Autopsy 1 day and Autopsy 2 process have been about – and boy, are we learning what we could have done better!
Ch9 = Communications and relationships
Very useful to read, no time to cover here.
Ch10 = How not to annoy people (process, emails, meetings)
Very useful to read, no time to cover in detail here.
The chapter included this useful description of facilitation.
Ch11 = What to do when things go wrong
Very useful to read, no time to cover here.
PART 3 = MANAGEMENT
Ch12 = Why leadership is based on trust
I certainly agree with the title of the chapter.
This author does provide some good content – but the best description I have read on the subject is still “Speed of Trust”.
Ch13 = Making things happen
Some useful tips in this chapter about making things happen (e.g. prioritisation, saying “no” and knowing the critical path).
Not as meaty as other chapters, though.
Ch14 = Middle-game strategy
The key principle here is “flying ahead of the plane”,
as the Project Manager.Everyone(?) knows this in principle, the good ones just manage to do it better.
Ch15 = End game strategy
The author continues the metaphor or flying to explain why landing a project is like landing a plane (i.e. it’s not often a linear approach).
This chapter is very worth reading.
Ch16 = Power and Politics
Some useful thoughts on power and influence.
I hope these comments have been of use to you?
The book is well worth reading, but don’t treat it as a comprehensive gospel!
[...] on our journey, there will be times in which a more prescriptive approach is needed (such as when I curtailed the UPIP project) simply because Trust is not possible with respect to that particular project, at that point in [...]