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.

I do not remember how many times I used phrase saying "if you are one in a million, in China there 1,300 people like you". I heard it somewhere and did not really know who coined that. Reading through "Prezentation Zen" I saw presentation called "Shift Happens", which uses comparison with China to amplify the changes happening in the world today. I could not resist sharing this great presentation with you:

Going to checkout winners of various SlideShare Contests for more examples of great  presentations.

I'm reading Garr Reynolds' "Prezentation Zen" and his points about efficiency of presentations, which can naturally be translated into efficiency of communication, resonated with my mind:

The presentation would have been greatly improved if the presenter had simply kept two questions in mind in preparing for the talk: What's my point? And why does it matter?

Now communication is more important than ever for me, since I work on-site with client and do not have luxury of face to face communication with my team. Should I be asked to generalize Garr's statement I would do it this way:

The communication would be greatly improved if the person speaking now would simply keep two questions in mind, when preparing to speak: Why my speech does matter? And what is my point?

I have heard dozens of perfectly made points, which unfortunately were not relevant and simply consumed the bandwidth. Alas bandwidth of communication is more limited than we usually think.

Keep that in mind and be an effective communicator.

Have you ever worked with, maintained, explored a system which looked and felt really great in one area, but was really awkward and clumsy in another one? That was an instance of an elephant on the crutches.

This often happens, when design specification was not consistent in the level of detail for different parts of the system. And here is how this may happen.

When you design a system, it is never going to be plain and the same wherever you look at. If you have a database and a user interface - those two parts are already different enough. Such diversity naturally leads to the fact that there are some parts that you enjoy working on more than others (after all we never like doing everything that we do).

What happens next is that you spend much more time thinking about parts you like (because there you use new fancy technology, or neat engineering approach, or who knows why). Therefore you add more details to design of those subsystems that you really like. The outcome of all of this typically would be a specification that is an elephant with crutches instead of hind legs, because elephant's butt was never you favorite part of the system and design of this "subsystem" never was detailed enough to make sure it is consistent with the front.

Ideally, your design should be like Google Maps: you should be able to zoom in and zoom out on any part you need. It does not make sense to have a map, which shows each and every tree in your neighborhood, but gives you only a vague idea about how to get to grocery store 5 miles away.

When developing and documenting design you should gradually and consistently increase level of detail in your specification. Ideally, difference in granularity of descriptions of different parts between any two parts of the system should never be more than one level. One possible way of zooming in would be to describe

• System + external interfaces, then
• Services and components, then
• Add their interfaces, then
• Add interaction (Sequence diagrams) and edge classes, then
• Components' structure and internal interactions, then
• Class-level specification for key requirements (functional and non-functional)

This is not the only possible way to zoom. However, when you have class diagram with methods and their parameters, but do not have stored procedures defined for your database, you are doing something wrong (or, hopefully, your design specification is not complete yet).

Design specification is only useful when it can help you answer questions you get during development. This essentially means that you should be able to navigate it and find things - which is zooming in and out and seeing enough to make the right turn.

Now when my commute went from 10-20 mins to 30-40 mins in each direction I quickly burned the backlog of podcasts. I gave a try to some new and so far I like what I hear. Here they are:

• Manager Tools Podcast
• Software Engineering Radio
• 37signals Podcast

What are some of your favorite podcasts?

Sounds familiar? :)

(via Geek and Poke)

Every once in a while you receive "Can you endorse me?" inquiries in your LinkedIn Inbox. There is something which I do not like about such requests, if they come without recommendation for you first. It is like saying "I've worked with you long enough that you recognize value of the work I've done, which also means that I can do the same, but I do not really think that your contribution is worth my recommendation. Can you endorse me?" In fact, your recommendation of someone is the best request for endorsement. Indeed, why do you want an endorsement from person, whom you do not respect enough to give your own recommendation. It is not better than asking a stranger to sign a petition that you are the smartest person in this street.

And remember: the one, who cares most (about the other), gets most out of relationship.

I'm currently working on site with client. The other day I had a conversation with one of the project managers and somehow we landed on a topic of inducing a change in organization. Especially, when the change needs to be supported by management and management is not very supportive, because the problem is not very high on the priority list. Depending on the actual environment and type of change involved here are two strategies that might work.

Get allies. Often times you and your fellow colleagues feel the pain, know the problem and see the solution, but management does not really understand what it is that you are trying to solve and therefore is reluctant to support you or allocate funds needed to implement change. What you can do it to get an ally, who shares your vision and is willing to take the problem and solution to the management with you. If two people show up with the same problem, it is easier to get attention and have manager spend time thinking about what you have to say. When you open a meeting you called to resolve this problem with "We've discussed this problem with such and such (and those people are in the room) and we are in agreement that solution would be..." it is much easier to get through manager's internal "why do I care?"

Propose to try. This is based on The Puppy Dog Close approach. Here is how Tim Ferris describes it in The 4-hour Workweek:

The Puppy Dog Close in sales is so named because it is based on the pet store sales approach: If someone likes a puppy but is hesitant to make the life-altering purchase, just offer to let them take the pup home and bring it back of they change their minds. Of course, the return seldom happens.

The Puppy Dog Close is invaluable whenever you face resistance to permanent changes. Get your foot in the door with a "let's just try it once" reversible trial.

There is psychological resistance to make perceivably big decisions without "proper" consideration, which, of course, never happens if the problem does not seem very important to management. By making the change temporary you lower the barrier for amount of consideration on the change. If the change will be for good, most likely no one will question the decision to make it. And, of course, if change for some reason does not bring the relief, you need to be the first to admit it and revert back to older procedures.

What do you do to induce a change in organization?

(Image by Dina Middin)

Recently I discovered that during 2nd International SOA Symposium they published SOA Manifesto. It follows the spirit of the famous Agile Manifesto, which provoked many discussion and debates over the actual meaning of the statements of that manifesto. (Not) surprisingly there are many other manifestos related to software. Here are some to name a few:

• The GNU Manifesto
• The Mozilla Manifesto
• Open Cloud Manifesto

But there is important thing, which puts SOA and Agile manifestos apart from others -- they can not be simply declared by an individual to work. While one can accept, for example,  the GNU Manifesto and act as declared and make a difference. With SOA and Agile you can not manifest something individually -- the team has to embrace these ideas together in order to make them work.

I wonder when (and if) we will move to team manifestos instead on manifestos of individuals.

Have you ever visited a farm? A farm which produces milk, or meat, or even wheat, or corn? If you've been there, I'm sure, you've seen many interesting things all over the place: tools and mechanisms, people and animals. I'm also equally sure, you haven't seen there one thing - variety. Meat farms do not breed cows, pigs, chicken and rabbits. Milk farms do not feature cows together with goats on their premises. Grain farms do not harvest dozens of kind of grain. Instead they specialize in something and they try to stay as uniform as possible with respect to animals they grow, grains they seed and tools they use. Why do they do that? Because variety inevitably means higher costs of operation, but farms can not benefit from variety. For them it makes a lot more sense to have 200 cows of the same kind, than 100 of one and 100 of another since they require different treatment thus rising the cost of support.

On the other hand there are enterprises, which directly benefit from variety - zoos! The more different species you have in the zoo, the more money you can charge for entry tickets, the more visitors you can attract. Yes, operational costs go up as you add more animals - obviously lion requires completely different conditions than pelican, and most likely you will need two different people with different skill sets to look after them. But since you are able to directly sell this variety to customers, it does not undermine your profits.

So, the difference between a farm and a zoo is in their relation to variety: it kills the farm, but propels the zoo.

We see examples of both in our day-to-day lives. We enter farm land, when we rent a car, call a taxi, use corporate computer, eat in McDonald's. We go to zoo, when we shop in the mall, eat in the restaurant, buy a vacation tour.

Look at you business, department, or team and see what you are running - a zoo or a farm. Chances are that you are running a zoo, when you should be running a farm. Run a farm unless you really know how to benefit from variety, which zoo has to offer.