Blind date, Part 2: The dog and the fire hydrant

“A lot of what we do may be just plain habitual”

So, how do I just apply a generic set of process on any project? Actually, depending on your project, some of them could be irrelevant. Few seem to make sense, but the templates do not match the data I am trying to capture. Few, people even expertly fill out sections in documents just because they exist with data perhaps not even relevant to the project.

I’ve had folks argue with me, saying, that doing this is as per PMP/ITIL guidelines or that they are using the organization’s standard templates, or replicating past success. All that documentation should be completed. There is no other way out.

That’s just it. This routine is viewed a lot of times a chore, something that has to be done to meet protocol. The processes and the resultant documents (many a time originating without the process steps itself) are in a lot of cases considered nothing more than another deliverable to the project. When viewed in this light, the sheer amount of process and documentation seem overwhelming.

Even the PMBOK guide tells you that a lot of the outputs from the process are used and updated throughout the project lifecycle. It even drops enough subtle hints at using the right process and customizing the techniques to suit your project. Understanding what these processes and their outputs mean and how they can be valuable in helping you comfortably manage a project. (Especially from the planning phase).  More about that in part 3.

You would be surprised by how many projects run without appreciating the reason for process. And how many processes in a project seem like the proverbial ‘fly in the ointment’ to a lot of folks, especially starting out in handling duties beyond development like work breakdowns helping with schedules. I am not denying that there are teams, organizations or people that approach the entry into the world of project function in an ideal way. However, being in the service industry, and having quite a few good friends out there as well, it’s pretty evident. Though the work gets done at the end of the day, there is a significantly better and structured way to get there in a lot of cases.

Blind Date Part 1: This wheel is perfect

“Things can’t be any better?”

There are processes defined and followed by every organization for all the work they execute. This is something the software service industry swears by.

I agree that process is important. It most definitely gives you an accepted approach to a task. It lays down the “tried and tested” rules of execution. It measures almost everything quantifiable in the project.

Can’t possibly go wrong with it, huh?

Well, maybe not, as long as whatever you are executing is exactly the same as the last successful project executed with the same defined processes. But, how often is that true?

Most people who would have executed more than two projects would feel that the projects are like fingerprints. No two seem alike.

Add it to our mix of different technologies, domains, products, tools, and organizational & customer environment influences and you get a thousand permutations and combinations of project types/styles.

That being said, processes play an important part of any successful project. They also contribute in a major way to overhead when not done right.

What you don’t do is always more important than what you do do!

That title is “Worker’s Dilemma” from a tiny book by Arthur Bloch on Murphy’s Law- Complete. Yes, That Murphy infamous for “If anything can go wrong, it will”. The theorem that has featured in my life time and again, and I am sure has paid an occasional visit to all of you.

I have had the good fortune of surviving a good number of projects in the software services industry. A lot of them were thankfully successful. Some of them, I have sailed through and then there were the ones I felt that I had to mud-wrestle a crocodile to make sure the project sees the light of day.

Why? Were they just technically challenging, or was there something that could have been done better? Every project has its share of the “Why is this happening to me!!?” moments. Some projects, more than others. There are reasons behind these, that you really do not need a crystal ball to see. And you don’t always have to learn it the hard way either.

Thought I should finally take the time out to pen down what I’ve learned over the past years, those bitter-sweet experiences and realizations if any, on what to do right.  :)  

Well, in a nutshell, thinking back, reflecting, and managing the next one a little better, in the process, learn something from the valuable comments and insights from all of you.

Appreciate your thoughts, comments, arguments, and feedback. Thanks!