I write about Software Development, General management and what interests me in Science and Maths. This is based on my experience as a Project Manager and what i read (books, articles, blogs).
If you are wondering about the 'everything else' part along with Project and General Management, i have deliberately kept it so that i can write about anything and everything i feel like. And 'everything else' is inspired by Hitch Hiker's Guide to the Galaxy Series by Douglas Adams. :)
During the build up to the Afghan war, one of the TV reporters made the statement "Amateurs talk Strategy; Professionals talk logistics". The saying actually means that though plan/Strategy is important, in a war having the right people at the right place with the right equipment/food is even more important. I hope all of us remember the poem, "for the want of a nail, a shoe was lost".
This is not to say that strategy is a bad thing and planning is a strict no-no. That is not the case. Planning is important and its importance is not understated here. But what has to be understood is that seemingly inconsequential areas (like logistics) have a major bearing on the outcome when you fight a battle.
You may be wondering what relevance the above quote has got to do with project management, but before we go into it, let me share an event that happened recently.
A person called me up and wanted a few minutes of my time to talk about his project. He actually shared a sob story about his project-gone-very-wrong with me. He had a long laundry list of what was wrong with the project. I asked him about his issue tracking system and version control process. To my shock and surprise, i was told that bugs and CRs are managed through mails and there was no version control procedure in place. Things were actually so bad that a functionality that the team mentioned as delivered to the client wasn't actually delivered. The project has a plan, MPP, WBS and a few more typical artifacts, but it was failing miserably.
The story above is a classic example of another project gone wrong though all typical artifacts were in place. This happens because certain aspects of Project Management are given more importance than what they deserve. And certain aspects don't get the kind of importance they deserve, because they are thought of as inconsequential. Ultimately projects fail because of what we don't do right more than what we do right.
Given below is an indicative list of activities/artifacts that are less important than they look and another list of things that are more important than they are actually treated.
Less Important (Amateur Territory)
Weekly Status Reporting
More Important (Professional Territory)
Setting and Managing Client, Senior Management and Team Expectation
Issue Tracking System
This list is neither exhaustive nor complete. The hall mark of an experienced project manager is the importance he/she gives to the 'Professional Territory' without undermining the 'Amateur Territory' in a manner that ultimately results in the project success.
Note: What follows is the notes taken from my study of Kano's model of Customer Satisfaction. I came across this model when i wanted to know if there was a structured approach that would help me prioritize features for software product development.
To evaluate a product or service, following parameters are very important
The value provided - this helps attract customersThe Quality offered - This earns customer respectProduct or Service innovation - This helps differentiate from competition But these are not perceived directly, but indirectly through the product and it's features. Kano's model help to group product features into 3 categories ( 6 categories, but only 3 are important) and there by makes it feasible to deliver value at a promised quality while offering innovation.
The 3 important feature categories are Basic featuresLinear featuresExciters or DelightersBasic features are that must be present in the product to be successful. They are also referred to as must have…
This article is a draft of a paper i started to write in september 2007 and left it where you see it today. The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome... Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project. All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use. But the problem is that people usually look at these factors in black and white. This may be ac…
During my early years in the software industry, i used to look at people who worked in projects with aggressive schedules, in awe. The people working in such projects talked about, long hours, working week ends and heroic endeavors in their projects. The people who worked in such projects were given more awards and rewards, compared to others. i thought that this was the way to be.
After working in projects with aggressive schedules, I realized that what I saw was only the silver lining and there was a big dark cloud behind this ( talk about what experience can do for you). The common thread that linked all the projects was that all of them exhibited one or more of the following. Project ended up delayed by more than 100% Project got cancelled Project got de-scopedProject has a high cost of maintenance. Having been burnt up by working in projects with “Aggressive Schedules’, (henceforth denoted as AS), I understand that projects with aggressive schedules cause more damage than what we …