Many junior PMs think that Change Requests (in our company we call them Change Orders) always come to project team from the outer space, whenever the client or other stakeholders want to change something, like increase the scope or tighten the schedule. They think that CRs are there to protect the project team from changes coming outside of the project.

The thing is that CRs are not only about the scope. There are many more controlled project parameters, although the scope is probably the most notorious when it comes to changes. And whenever you need to change any of these parameters you need a Change Request:

• Scope
• Budget
• Schedule
• Specifications
• Quality (if you run projects better than others and really control quality)

When the customer wants to add something to the scope of the project, you need to issue a Change Request to adjust other parameters accordingly. When you need to change schedule, you issue a Change Request to communicate  the change and get approval for it. So Change Requests are not only and not always incoming, they can and should be outgoing to communicate important things, which happen to the project.

Change Requests are meant to protect project stakeholders from silent changes in the project. As much as you want to be informed and be able to react appropriately to the additional work coming your way, the same way project customer wants to be informed and be able to do something on his end, if you decide that final delivery date needs to be moved.

Change Requests are means of communication and no wonder that not doing this part of communication properly can put your project at significant risk. Next time not only wait for CRs to come, but be sure to communicate the changes you initiate to other project stakeholders.

Also check out The Top 9 Reasons Why Projects Fail at The PM Podcast. Communication done right is 80% of successful project.

Sounds familiar? :)

(via Geek and Poke)

Toy Story 3. Release date: June 18, 2010. 323 days from now. Does not that amaze you? No? Most likely you are not a Project Manager. And certainly not a software Project Manager.

In software world we know how hard estimation is. And to date I have not met a Project Manager, who would commit to a delivery date a year from today. Well. one can commit, but what about keeping this commitment. Recently Boeing postponed first flight test for its Boeing 787 Dreamliner till early fall. This might not sound bad, but what if originally this aircraft was scheduled to take off in 2007?

Surprisingly, in entertainment industry they know how to give promises and keep commitments (at the very least with release dates). How do they do that? I do not know for sure, but my take is that the "secret sauce" should be in very effective scope management. And, of course, expectations management.

When film is announced not more than title, broad story topic, and, probably, some of cast is told out. More details are given out to feed public's interest, but I bet they never tell us about something that can not be done by release date with high degree of confidence.

There is certainly something to learn from this approach.

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

• Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
• 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
• Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
• Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
• Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.

[caption id="" align="alignright" width="180" caption="New roof at Wimbledon"][/caption] For years I've been using Wimbledon tournament as an example of really good uncertainty management: with all those games taking very different amounts of time, unpredictable rains (in 2008 man's final was interrupted twice) - it is a scheduling nightmare. Yet, man's final always happens on the 2nd Sunday of tournament (except for 2001 when it was raining on Sunday and final was delayed till Monday).

Wimbledon is scheduled for 13 days, beginning on a Monday and ending on a Sunday with the middle Sunday a designated rest day. The five main events span both weeks, but the youth and invitational events are held mainly during the second week. Traditionally, there is no play on the "Middle Sunday", which is considered a rest day. However, rain has forced play on the Middle Sunday three times in the Championship's history: in 1991, 1997, and 2004. On each of these occasions, Wimbledon has staged a "People's Sunday", with unreserved seating and readily available, inexpensive tickets, allowing those with more limited means to sit on the show courts. Additionally, if the tournament is not completed by the end of the second Sunday, all remaining matches are postponed until "People's Monday".

Wimbledon on Wikipedia

Tight rules, uncertain conditions - great execution!

Now the problem with rains is fixed at its roots: roof at Wimbledon's Centre Court. This does not fix the problem complete, as other courts are still under open skies, but weather area on Wimbledon's home page gradually becomes less relevant.

Many years ago when I was at school I was serious about orienting. Once I even was 3rd in national championship. And the trainer always told us "Stability is a sign of mastery". No matter how fast you are on the training you've got to be able to repeat this result in real competitions throughout a season. Also you've got to be proficient with basics of the sport - you can not succeed without consistent results in long-distance racing. And no one in your team is going to take you seriously if you say "This will be my showtime" when your results record is like a wave of highs and deeps. When you are developing a software product you, first of all, run against your competitors on quality. And you will only be able to succeed if you can deliver consistent level of quality. Consistent external (perceivable by your users and customers) quality can only be achieved through stable internal (visible to your staff) quality. Of course, miracles sometimes happen and you can get a decent quality product without maintaining internal quality metrics. But you will never able to sustain this quality before you get internal processes and practices right. (By the way, if you think you've managed to do that, drop me a note -  I would love to know how it worked).

Jason Yip got a great quote on this from The Practice of Programming:

Consistency leads to better programs.  If formatting varies unpredictably, or a loop over an array runs uphill this time and downhill the next, or strings are copied with strcpy here and a for loop there, the variations make it harder to see what's really going on.  But if the same computation is done the same way every time it appears, any variation suggests a genuine difference, one worth noting.

Master your skill and deliver quality everyday even if no one notices that. And once you need to do your best you'll do that as you always do.

Software developers like being "agile", whatever this means. They say being "agile" liberates their creativity and lets positive energies of the Universe flow through them to the code to (hopefully) solve customer's problems. They are committed to using all the practices that e.g. XP suggests, but it generally would be better if somebody else writes unit tests. For me definition of "agile" changed forever when I first watched David Anderson's interview "Writing Agile Software" and read his book Agile Management for Software Engineering. All the other books on "agile" topics I've come across focus of how freaking cool it is to use agile to develop software, of course, from the point of view of developers. And you are a, hm-m-m, short-sighted conservator if you want developers to do development with, say, RUP.

"Agile" does not equal to "Say no to BDUF and documents". David in his book explains what is agile and why it is better for clients and their businesses.

Jurgen Apello in his blog provides a review for this book, but focuses mostly on the form, not the meaning. True, the book is not fun and makes you think, but it is gratifying when you finally get the clue. Again, this book is not about the fun you get working on agile project, it is about why agile works in business landscape.

Anyway, if you want to better understand the book, my suggestion is to watch the video first.

If you follow advances in agile project management you've heard of Declaration of Interdependence (compare it to Agile Manifesto). This Declaration reflects progress of software development from romantic profession of "ugh, this guy can command a computer" towards pragmatic business and established engineering discipline. We no longer can afford doing technology for pure technology sake. Economics comes into play. Surprising thing to me is that since I first learned about DOI I haven't heard of it at all. Despite of being a well thought out piece of knowledge it did not get referenced too much. Mike Griffiths provides a good analysis why this may be so.

Mike references the Made to Stick book which happens to be on my bookshelf also. Looks like I need to push it up on my reading list.

Today I found some new answers to questions I was asking and was asked. Here they are:

Q: How do you define a "small" and "large" project?

A: Small project is project with homogeneous development environments. In large project the environment is heterogeneous. For instance, C# + SQL is homogeneous environment, while Java + Flash, or .NET + Perl are heterogeneous.

This definition correlates to size of the project measured, say, in functional points. When project size grows more supporting utilities, services or components are required which are often implemented with technology very different from core product platform.

Q: How do you define "mature" developer?

A: Mature developer, I would even say, engineer understands that technology is not a goal. The goal is business value, technology is only a means.

Have you ever been told that new version of XYZ came out yesterday and we need to migrate to this new version as soon as possible? Great engineer is the one who finds best technical solutions with the imperfect tools he's got.

Q: Who is a manager?

A: A manager is a person who understands trade-offs.

Manager understands what choices mean, what are the implications and why one of several alternatives is chosen. Good managers see choices where others can only see a straight way.

I've already mentioned several times that I absolutely love Advanced Selling Podcast since the first episode I've listened to. One day I said to myself: "If there is selling podcast, there should be project management podcast". I went to Google and found the Project Management  Podcast. I've downloaded a whole bunch of episodes some dating back to year 2006. And I have to say that I'm happy with what I hear so far. One particular merit of the PM Podcast site is Helpful Resources section which references all the books, articles or whatever that Cornelias interlocutors mention during the show.

These days I'm highly into team dynamics and all other questions related to building effective team. So I particularly enjoyed the "Overcoming Team Dysfunction" episode and the following articles that were mentioned:

• Functional and Dysfunctional Teams
• Dealing with Dysfunctional Teams