Berkun reading group discussion

What did you find most/least useful in chapter 4? The discussion and commentary begins here.

I hear crickets here - has no one survived to chapter 4? Oh Noes!

So behind this week! It's SXSW here in Austin so that might have something to do with it...

I completely agree that conciseness and simplification is the order of the day in *all* business writing, including the vision/goals doc for a project. LOVE the references to the length of Ten Commandments, US Constitution, etc. (p. 79)

Also really happy to see visualizations get an entire two pages (83-85) in this chapter! Yes! Every vision should be required to start with a visual aid. Will some just look at the pretty (or not-so-pretty) graphic and close the document without reading the rest? You bet, but that's more exposure to the project's essence than they would get if it was an entire page of text. (Something's better than nothing theory.) And, if nothing else, creating the visual is extremely impactful in forcing the PM/leadership to distill down the the varied answers they inevitably came up with to what-are-we-trying-to-do-here conversations.

Draw! (I love the free LucidChart for this, btw.)

Scott, at this point in the book, I'm definitely wishing there was a "project guide" of questions and exercises to go through as a project moves along, based of the principles and suggestions in the text. Have you considered something workbook-like? Of course, I could just go through my highlights in the book as I work through each project, but I have a feeling that something more directed or step-wise would be better at jogging my memory on all the great advice contained in the book.

This is also something I feel like is missing in all of the online PM tools we've tried. Yes, you can setup templates and checklists of the typical PM questions/tasks but it seems like more trouble than its worth. Sometimes it even obscures the actual project work. I'd be interested to hear everyone's approaches on how you organize/track/present the "meta" of a project.

Thanks for keeping the group going! Hope we can power through to the end. I'm learning a lot from the book and posts/questions here.

Kye: you might feel behind but you're the first to comment on Chapter 4, so kudos to you :)

The challenge is every organization and team are so different. To have one checklist for everyone would either be too generic to be useful, or too heavy to be easy to use. The burden is always on the team leader to do some thinking for each project.

On visualization: there's a quote by Mike Davidson that I like:

"A prototype is worth 1000 meetings"

Designers know this. A sketch, a screenshot, a drawing, all compress so much information and decision making into them and generate far better discussion that 30 page specs do. But since most managers and engineers have so little design training they prefer other means, despite how much more effective it is in this case to show and not tell.

The only approach I can see working is a workbook that was really short and simple, and focused on questions you, as the project leader, have to ask yourself.

Finally caught up with Chapter 4. Good stuff. As far as SMART (Specific, Measurable, Action-oriented, Realistic, and Timely) goals, I heard that a leaner approach is to just call them MT goals, because by virtue of making them measurable and time-bound, you get those other qualities for free. Do you buy that argument or are those other qualities independent and important to strive for?

The challenge is every organization and team are so different. To have one checklist for everyone would ..."

Scott, totally makes sense.

Definitely think a tool that prompts the PM to think - not a heavy-handed "checklist" - would lead to success in the largest variety of situations.

What about an interactive tool that could morph itself based on input from the PM given a set of project variables? Then the PM isn't sifting through the bullets and questions that really only apply to a huge enterprisey project when she/he is on a three person team.

It also seems like there would be a lot of value in having an "invisible layer" of questions/advice/tips easily accessible in context of your current project. To use this chapter as an example: from within the vision document you could access "qualities of a good vision statement" as well as "questions to test if the vision needs a mid-course correction" and so on - that were specific to the type of project previously identified.

Of course, after you go through 100 projects, a PM probably has it down out of sheer experience. But for those of us that belong to the teams of those PMs on projects 1-99, it sure would be nice!

There was a big trend in the late 80s called expert systems - the idea was: why can't we use basic AI to model what experts know about their expertise and use that instead of the experts? It turned out that for troubleshooting a car or the plumbing of your house, these systems were helpful, but for truly complex/subjective skills like management or leadership the results were never as good. Good managers and leaders are rare - and it's not because of lack of knowledge, there are simply too many subjective variables to abstract the skill into simple rules.

On the positive end there are books sort of like what you are after. My favorite is: Roundtable on Project Management. Each chapter is a discussion of a type of issue, with different thoughts about common tough situations for that issue and opinions on how to solve. It's not a checklist, but it avoids the trap of checklists (this book never tricks you into believing there is a trick or secret) - http://www.amazon.com/Roundtable-Proj...

I'm still alive. It took me a while to get through chapter four. My favorite parts of chapter four were the following:

1. How do you create good goals?
2. Patterns of poor visions
3. Lame vision statements
4. Excellent examples of vision statements
5. Why "visions should be visual?"

In the section on creating good goals, Scott cited two approaches - SMART goals and devil's advocate approach. I would like to add a third approach: ask mom. When creating good goals for projects, I ask my mom or fiance if they understand my project goal. About 1/3 of the time they don't.

I would've liked to see more examples of the following:

1. More exemplary examples of vision statements from other domains
2. Additional examples of converting abstract vision statements into pictures.

I am creating a vision statement for a new project. I lead a team of QA and DevOps engineers.

This is my one sentence so far and I would appreciate feedback:

"The user acceptance test (UAT) environment uplift project will fix the top five complaints from users."

Three of the five complaints are:

1. The data required to verify the new features of applications are missing
2. The downstream system for processing my order is unavailable most of the time
3. When will feature X be released to the UAT environment?

How do I make this visual?

1. Show a before/after visual with a broken application missing data.
2. Show a side by side picture of a blank calendar; picture of a calendar with the feature release schedule

Ravi's comment also touches on a point of confusion for me: Should there be one vision document for the whole company? Should there be a vision document per department? Per team? Per project? If there is a hierarchy of vision documents, to what extent should they be drawing upon each other?

I'm helping build a technology department from scratch in my company, a financial tech startup. For many reasons, the department will share (and inform) the company's vision, but there will be technology goals that are too specific (e.g., our intranet should be simple, fast, and responsive). If we maintain a singular vision document for the whole company, how do we address fine-grained goals specific to departments or projects? If we maintain multiple documents, how do we reconcile conflicts and differences, ensuring that the company's overall mission and goals are preserved at all levels?

Shiran

Ravi wrote: "I am creating a vision statement for a new project. I lead a team of QA and DevOps engineers.

This is my one sentence so far and I would appreciate feedback:

"The user acceptance test (UAT) envi..."

The beginning sentence looks more like requirements to me. I.e. We need to fix these 5 problems. If the project has been defined like that then perhaps it does not require a vision statement?

Ch 4 on Vision is tough because my experiences have been that such things are too often perceived to be the domain of VIP's and the 'tactical' execution of it is left to the PM's. However, I've learned to fight for a seat at that table because when the vision is actually something you can use to rally a team with, help make decisions with, settle debates with, then it becomes really valuable. For those in consulting (like me) you can sometimes find the essence of vision in the winning proposal or contract summary, as a starting point. For others inside a company, I think it's actually harder, especially if your company is not well skilled in execution (Larry Bossidy's book on this is excellent) or in practical project management.

Ravi:

You'll need to be creative in visualizing something not being there.

2. The downstream system for processing my order is unavailable most of the time

How does the user know it's unavailable? Show a screenshot of that sad screen :) In other cases where users have no way to obtain certain information I'd show the screen people *try* to go to to get an answer (a help system?) with their unanswered query shown.

You can also do an informal usability study where you ask a customer to try to do the task, and videotape them trying (and failing) to do it.

Shiran:

It's the job of leaders and managers to make sure that the vision executives have is translated properly down to each team and person. It's a primary part of their job. It's not reconciling conflicts so much as guiding the creation of the vision for every new project to line up well (or lead to a change) in how the higher level goals are defined.

In most organizations each layer of management has a regular meeting where they discuss what their current goals are and conflicts are reconciled. Vision/Goal documents can help with this.

I'm going to be honest, I'm not sure any of my large projects have had a good vision statement. So reading this again was a revelation. I have had excellent scope statements even listing things that were out of scope, but I think the larger projects veered away from the initial vision of the project. I'll be including vision statements along with my scope statements going forward.

For me, no aging. Everything was something I needed to read!

Rachel: glad the chapter was good for you!

The vision statement is good or bad to the degree the leaders of the project take it seriously. Some leaders on projects I worked on at MSFT took it very seriously, and made it part of every leader's thinking. Others, not so much - quality of any "process' always reflects the the leaders of the project, or the company.

Scott: Thanks for the feedback on visualizing something not there. It worked with my end users.