Several years ago on one presentation I said that world became really small: to any place where you might be interested in visiting on business you can get within 24 hours. Sometimes you do not even need to get there, because world is not only small it is also flat as Thomas Friedman described in his books. Here is great video of his lecture in Yale:

Many say that configuration management is hard. It is. 100% correct, "as the books says" software configuration management is hard. It takes tools, skills, discipline and effort to build and support reliable and effective software configuration management process. It is especially difficult, when there is already some process in place and improvement involves change.

My experience shows that it is particularly challenging when it comes to non-source code items like documentation and release packages. Can you imagine following dialogs with project team members? I can…

Managing source code:

--Is it necessary to follow Configuration Management practices, when you work with the source code? --Yes!

--Do you use source code control system during development? --Sure!

--Would you start coding without SCC in place? --Absolutely not!

Managing release packages:

--Should you manage configurations for you release packages? --Oh, yes!

--The best way to do that is to be able to recreate any version of release package... --Oh, yeah! That's the best way, especially, if you hook this up to automated builds and tests...

--Do you do that? --Well... You know, that requires time to setup. We are so busy with other tasks actually writing software, so we never actually got to that... And, by the way, our existing process is not that bad...

--But still you can get all the previous release packages, right? --Well, I guess so... We have a share where all the releases are uploaded.

--Do you delete files from there? --I think so. When we need to.

Managing documentation:

--Should you keep track of the versions of all the development-related documents that you've got? --Yes, definitely!

--So you do that, right? --Well... Not exactly... You know SharePoint (or another tool, you name it) is somewhat difficult to use (or setup). We just put the file in a shared folder or sync over the e-mail. When the document is final, we put it into SharePoint.

--I see... But you do change version number on the document each time you edit and keep it somewhere, don't you? --No, not really. Do we need to?..

Generally, the further you get from the source code the worse it gets.

There is a simple, not ideal, but simple remedy to this, which lies in mimicking what source code control system does:

Never overwrite or modify files! Always create new!

After all, we all have got 500Gb drives in our laptops - we have to put them to work.

By this time most of us (at least those who care to make our lives better) have made their New Year’s resolutions. From what I hear here and there most of these resolutions are around new things which you are going to do this year:

• work out regularly
• read more books
• spend more time with family
• improve foreign language skills
• etc.

As you see all of these resolutions are about new things in your life, they are about doing things you did not do before. However, there is another popular resolution, which is, in a sense, exactly opposite:

• quitting smoking

This resolution is about not doing something, thus creating a room for new things in your life. Indeed, ten 5 minute smoking breaks give you 50 extra minutes each day, when you get rid of this bad habit. Extra bucks that you save on not buying cigarettes give you additional opportunities to do something meaningful to you and those around you. And this is not mentioning your health and wellbeing. At the end this negative resolution creates additional time and resources capacity you need so much to act on your positive resolutions.

I believe that each positive New Year’s resolution should be complimented by a negative one, which will make it possible to do what you resolved to do.

If last year you spend substantial amount of time fixing and reworking what your subordinates did, you need to resolve to stop doing that and instead focus on improving their skills to avoid those reworks in the first place.

If last year you engaged in many activities simply because somebody asked you and technically you can do that (and, between us, do well), you need to stop doing that and make your own conscious decisions about what you do and what you don’t.

We only have 24 hours a day and we always use them up. Each day. In order to start doing something, you need to take time from something else. Unfortunately, we can not create time out of nowhere.

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.