Project Potion - New Technology for Communication

The Art of War - Chapter 2 - Entry 1 - Knowing the Cost

"To raise a corps of a hundred thousand

 A thousand pieces of gold will be spent each day."

The second chapter of the Art of War begins with Sun Tzu laying out some basics about materials required to wage war. This kind of thing happens quite a bit throughout the book and it can be pretty distracting for Project Managers because our brains have been conditioned to start tracking these as requirements that we'll have to obtain at some point.  The run up of all these requirements  leads to the statement about the rate of gold per day and the fact that you can't even consider getting an army until you have that covered. The point of all this is to show that in war, there is cost, and that before you can start on the things you think you need to obtain (people to do the work), you first have to account for a whole bunch of hidden costs that you need to address before you go get people.

Bottom line...whether it is war, or a project, getting things done is expensive and there are going to be things that are less obvious or sexy that need to be covered. Before you take anything on, make sure you have a firm grasp of the cost. 

"The cost of an interpersonal Challenge is primarily an emotional one. Nonnegotiable conflicts can be very painful, since success generally comes through ending the relationship or changing ti into a very different one. Therefore, careful evaluation and acceptance of the emotional costs of your Challenge are essential to your success."

For Sun Tzu, the cost includes the lives of the soldiers and all the people who are going to have to work so hard to support them. While most project managers are not normally putting team members into direct mortal danger, the cost of the project may mean other projects do not get done... and depending on what choices are made, the business or company could be at risk, which does pose a direct threat to people's ability to work and earn a living and places them in harm's way.

We need to understand the cost of what we take on and what the ramifications of what we are doing are so that we can make responsible, informed a choices while managing the project.

Quotes are taken from The Art of Strategy by R.R. Wing

Project Potion #14 - Vuvuzela

Why an Iteration is Not A Mini Waterfall

When I am working with Project Managers who are in the throws of trying to learn Agile, there are certain discussions (debates), which can indicate that the person is going to have more of a struggle with making the change. These are usually the PMs who quickly grasp the flow of the process, but immediately begin second-guessing the system, and all of this usually happens without the PM even realizing it. After all, if you have been around a bit, and you are a halfway decent PM, you look at everything that enters your path as a potential threat to your project and start working out how you are going to get around it. This is what we are taught to do – find a workaround.


I think the bigger issue though, usually stems from the fact that the PM often does not recognize how their own expertise can be the obstacle. One of the ways this often manifests itself is through a question or declarative statement/argument about how the PMBOK is clearly, already Agile and these iterations or sprints we are talking about are nothing more than mini-waterfall projects.


Just in case any of the mini-waterfall people happen upon this… I mean you mo harm. I spent about 8 years inside that argument. Please bear with me a few minutes and this will make more sense.


I have learned my lesson about trying to engage in an argument against the perception that a sprint (or iteration) is just a mini-waterfall. I don’t agree with it, but it is perception, and my experience has been that getting pulled into this one kind of like trying to debate whether Sammy Hagar was a better front man than David Lee Roth.


To me, the real issue comes down to something completely outside the steps of the process itself. A traditional PM can make all the arguments they need to in order to maintain their death grip on the belief that everything in the world can be broken down into a traditional (waterfall) project. But, no matter how much Kool-Aid they’ve consumed, there is one thing which cannot be avoided, and which they cannot deny…


A waterfall project schedule is nothing more than a guess.


"…But little Mouse, you are not alone,

In proving foresight may be vain:


The best laid schemes of mice and men

Go often askew,


And leave us nothing but grief and pain,


For promised joy!"

(from "To A Mouse" by Robert Burns)


Yes, it is an educated guess and yes, there is usually math involved and we all know that if there is math, it must be true. Math aside, a traditional project schedule is just a guess based on what we think we know will happen, made at a point where we think we know enough to predict the future. (And I think we all know how good we project managers) are at predicting the future.



So, in managing a project, a significant part of the PMs gig is to come up with this educated guess and then do his/her very best to make sure to bend the very fabric of reality to match the guess. The idea is to manage to the plan.


In Agile, we focus more on the team and what we can do in order to better support and enable them, because it goes (Theory Y Alert!) that if you’ve got a bunch of smart, motivated people, you give them what they need, a clear objective and the power to make smart decisions, that the rest will take care of itself. (Remember – it says Theory Y above, not Theory X).


So, regardless of the steps in the process, the whole value system is completely different. A PM who is looking at the world through a waterfall will see the steps in the process as the thing that exists to make sure everyone stays on schedule as planned. An Agile PM is one who looks at the process as something their to support the team’s ability to perform. At the end of the day, both sides need to get stuff done, but a traditional PM uses the schedule to do this, an Agile PM enables the team to do this.


To me, if a PM is locked into the vice-grip of trying to prove that Agile is something that is already covered in the PMBOK, working their way out of that Gordian knot is usually something they will have to work through on their own, but if they can see the variance in the structure of the value system, and how that vantage point impacts their actions on the project, it is definitely a step in the right direction.


(And yeah, I’m willing to throw down for Hagar any time, anywhere.)

Project Potion Special Interview with Johanna Rothman on Agility and Programs

Breaking Radio Silence

I have lots of excuses... but, they are only excuses. However, I am very happy to report that I am now working for ProjectWizards heading up their new US company. I'll be writing more about this later both here and in another blog I'm doing on the PW site (link will be forthcoming).


In the meantime, this is something I stumbled upon recently that I think is very cool:
The Tao of PM Blog

And, I have a few Project Potion videos below. I'll be keeping up with these regularly from now on.

Project Potion Episode 11 - The Unpronouncable Volcano

Project Potion Episode 12 - iPads and Ashclouds

Project Potion Episode 13 - The Episode Without a Name

Malaysia Scrum User Group Kick Off - Notes and Videos

Just over a month ago I had the great pleasure of making a trip to Singapore and Malaysia to teach Certified Scrum Master classes. It was my first time teaching in Singapore and it was a very cool experience to teach such a sharp bunch of folks. The highlight of the trip though was co-teaching in Malaysia with Mike Sutton and helping the folks at ATSC (http://www.asiaictpm.com/default.htm) with the official kick off of the Malaysia Scrum User Group. The class in Kuala Lumpur was pretty huge for a CSM class (56 people) and it would not have been possible without Mike Sutton who lives in the UK but has been spending time in Kuala Lumpur working on some projects for his company WizeWerx (http://www.wizewerx.com/). Mike and I have very different backgrounds and I think I probably learned as much from him as anyone in the room.

Along with starting up the Scrum User Group, ATSC has also started a special networking group called MSC Circle to help raise awareness and networking opportunities for the Scrum Masters in KL. During the event I had the chance to shoot some video interviews with a few of the folks who took the class. They are embedded further down in the post.

If you'd like to learn more about the Malaysia Scrum User Group please go to http://myscrum.ning.com/ and sign up to hear more about the great things that are underway there. My good friend SK Khor, who I have had the pleasure of volunteering with for a number of years through the PMI IT&T SIG where he has served as the Asia Pacific Regional Director is heading up the group with support from MDeC (http://www.mdec.my/), the Malaysia govt. group that is responsible for helping establish and promote the growth of IT in Malaysia. Based on the work SK did with the IT&T SIG, and the fact that we've been able to grow the number of CSMs in the region to 80 since December, I think there will be a lot of activity in the region in the coming months.

I had a really great time on the trip and being a part of the classes and the kick-off event. I have a bunch of people I owe thanks to for the experience. None of it would have been possible without Mike Sutton, the folks from ATSC - SK Khor, EK How and Nan Ping Lee, as the incredible support from MDeC COO, Ms. Ng Wan Peng and Ms. Aiza Zeyati. On top of all this, I would just like to say that the people at the Scrum Alliance (http://www.scrumalliance.org/) rock like Hagar. Jim Cundiff, Tobias Mayer, Howard Sublett, Maria Matarelli and Tom Mellor, who was kind enough to record a video welcome to the members of MSC Malaysia for our opening event are some of the most responsive and supportive people I've run across in my 10+ years of volunteering for professional organizations. I owe all of them many pints.

And now, on to the videos…

Project Potion 10 - 6 Ways to Beat Project Planning

Project Potion 9 - Dress for Success

The Art of War Chapter 1 - Entry 6 - "The Plan is useless..."

At the end of the first chapter of the Art of War, Sun Tzu gives direction that may make the strongest case for project management in the entire text.

"Those who triumph,
Compute at their headquarters
A great number of factors prior to a challenge"*

He goes on to explain that those who spend less time planning do not succeed. According to Sun Tzu, more planning = greater success, less = greater chance of failure and no planning at all pretty much guarantees you have no shot.

The first chapter of the Art of War ends with Sun Tzu claiming that by observing the time spent in "computation" he can determine whether or not one will succeed in their efforts.

From a PM's standpoint, this has relevance on a number of levels. The most obvious application would be to the idea of actually planning out a project, and if you follow the rest of the lessons of the Art of War, this is going to end up bringing in many of the elements included in a traditional project plan. Things like risk planning and developing a communication strategy are critical aspects of Sun Tzu’s formula for success.

One application that might not be so obvious is how this planning can play out on a smaller scale. Something as simple as a business meeting, offers a great opportunity to prove out some of Sun Tzu's claims. If you've ever been in a meeting where you arrived not knowing what was going to happen, or what you were going to say ahead of time, you are probably already all too familiar with the formula for defeat that is mentioned above.  For my own part, this is a lesson that took a long time to learn, but over time I have learned that if I make the time for "computation" before a meeting, things go much better. In terms of preparation, working out things like how the Five Measures fit within the context of the meeting, thinking through what will take place based on who is likely to be present, what objectives or motivators they might have, who might say what, how the others in the room will respond, and especially, how to raise the issues I need addressed as well as how to respond to the questions I'm likely to be asked, seems simple but it is unfortunately something most people don’t take the time to do. It may sound like a lot of work, but my experience has been that once you get into a habit of doing it, this tends to come fairly easily. Whatever your goals in the meeting, even if it is just to get through it with your job intact, putting in the time to prepare before hand is just basic risk management. It will give you the freedom to devote the time and attention necessary to cover the things you were not able to think of before hand.

If success in the meeting equals getting your issues addressed without losing credibility, taking the time necessary to be prepared to participate with confidence and ease is just basic risk management, the same as you’d do on any project. And as for the others around the table, as Sun Tzu says, examining they prepare will give you a lot of insight into their ability to succeed or fail once things get underway.

While it can be fairly simple to see how this applies to Project Management, it has a lot of relevance to an Agile approach as well. If taking an Agile approach is intended to offer the freedom to handle constant change while incrementally working towards a desired goal, The Art of War in right in step. The basics of things like forming the team, having the team determine how they will best work together, what the vision statement is, etc. are all part of the “computation” Sun Tzu is talking about. These practices have even greater application later on in the Art of War. In a later section of the book Sun Tzu talks about the need to be fluid and adaptable, in order to do this successfully, someone leading an Agile project, or an Agile team, still needs to take the time to understand the basic concerns mentioned in this chapter.

The bottom line is, success is determined by your ability to make the time to learn about what you are facing and considering what will happen when things get underway.

Or, as President Eisenhower put it, "The plan is useless; it's the planning that's important."

* Quote taken from "The Art of Strategy" by R.L. Wing