Is Project Management a commodity or a craft?

Some days back I visited the Regional Transport Office of Bangalore North district, more commonly called RTO office. For those unfamiliar about my part of the world, RTO issues driving license if you pass their written test and driving test.

Bangalore, and I guess many of the cities in India, is teeming with driving schools. As the name would suggest, these folks teach you how to drive. In Bangalore and again, probably in other Indian cities, driving schools have, in a way, exceeded their brief. They also help you get the driving license. It is not uncommon to see a driving school agent chaperoning young would-be drivers around the RTO offices, filling up forms on their behalf, making them rehearse the driving rules and in general making them feel at-ease. With the passage of time, this has been stretched to such an extent that many would-be drivers go to a driving school, not to learn driving but to get a driving license!

Does this sound familiar? Rather very familiar? Isn’t this very similar to what is happening of PM education? You don’t see much of PM education happening around except maybe people getting coached to pass an exam. Traditional colleges and institutes do not offer PM as a course except maybe as an elective. The ones that do offer are not necessarily aligned to the practice.  Add to it the growth in number of PMI^® registered education providers who at the best provide only PMP^® exam prep programs.

As per PMI^®’s website an R.E.P. program has been designed to enhance the ongoing professional development of PMI^®’s members, those credentialed through PMI^® and others in the project management profession. But as time passed, a good number of them are now merely PMP^® exam coaching centers, with more following the suit. Some of them guarantee you passing the examination. A savvier few would even return your money back if you do not pass. Being a project management mentor, I have got requests for help in filling up in the PMP^® application from aspirants. (I feel like screaming at such requests!)

The conflict between credential being a commodity versus it being recognition of a craft (A craft is a skill, especially involving practical arts – Wikipedia) is a much debated and discussed topic in multiple forums. The jury is still out on this decision. But in the meanwhile, someone has to take serious look at PM education.

Coming back to my story, I had gone to the RTO for my daughter’s driving license. Even if she gets it, I would be really wary of handing her my car keys. I hope the powers-that-be in the industry do not share such apprehensions about a PMP^® certified project manager!

Eager to know if you would agree or disagree with me. Please do write.

Knowing your customer’s business.

I drive around in a Mahindra Scorpio shown here. It gives me unfair advantage on the roads in Bangalore where the right of way is based on the size of the vehicle! Lest you think so, this blog is not about the comforts of Scorpio or the horror called Bangalore traffic.

It so happened, some days back I rode in this SUV with my friend who is a mechanical engineer. As he got down, he looked back at the vehicle for a moment and said “Tell you what, my team designed the gear box for this SUV. Mahindra chose the design from a couple of prototypes we had made. Today, all the Scorpios in the country run on my gear box design.” Otherwise very restrained, my friend had to struggle to hide his sense of pride when he said that.

As you would have guessed, my friend does not work for Mahindra but his organization provides services to them, typically as projects.

This conversation set me into thinking. How many of us in our projects appreciate why the customer has entrusted us with the project? Or how many of us know where the project fits into the proverbial larger picture?

If you ask me, my answer would be “Not many”. Some if not most of, projects run on the classical iron triangle of scope, schedule and cost. The team gets the project with the requirements. It is executed hopefully in schedule and within costs and delivered back to the customer. Then you return to your home team and get reallocated to the next project in line. Taking further liberty, I would like to say that the PM is worried about on-time delivery and the team about sale-ability of the skills acquired through the project. And the twain sometime does not meet.

The basic question is should the project manager and the team know the customer’s business? Is this a nice to know or badly needed piece of information? Probably, the later.

Let me paint a few scenarios.

Is your project a part of mature well proven product? If yes, you can expect clear requirements but the customer would expect quick turn-around time.

Or, may be your project is a part of a brand new product/platform. You can expect uncertainty in requirements. (I am sure my friend in the above story would have faced a lot of this.) Don’t fret over frequent requirement changes.

Or is the customer meeting some legal compliance through your project. Expect very clear requirements but don’t get frustrated by thorough verification with a magnifying glass, almost nitpicking.

So, knowing the larger picture does help you in managing your project better.

If you become invisible and get into some of the project meetings, you will get to hear a lot “we and they” talk (or should I say “us versus them”, anyway). Like “They always change requirements”, “They do not know what they want”, “We are already overworked” etc. If you know the customer’s business, you will have less reason for the “we and they” talk.

I want to end this blog on a philosophical note. Inherent in the human heart is the desire to be of some use to somebody and to leave a legacy behind. Knowing the customer’s business fulfills this desire. Like “thousands of vehicles ply on the bridge that I worked on” or “every time you talk on this phone, my compression software kicks in”.  How do these statements compare with “we completed the project within 10% schedule variance but got beaten on cost escalation of 50%”?

Need I say more.  As usual, eager to hear your views and experiences. You could also vote at http://polls.linkedin.com/poll-results/95180/gamah.

Observations on the practice of estimation

I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”

I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.

Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.

Inherent inaccuracy: All the project managers (and their supervisors and customers) know that by its very definition every project is unique. The very first slide in any project management training course would say this. But probably this realization is only at the intellectual level. None probably wants to accept the fact that along with uniqueness comes uncertainty which in turn leads to inaccuracy in estimation. Moreover, this inaccuracy cannot be wished away till you are actually done with all the activities.

Single value certain estimates: Given the inaccuracy, shouldn’t the estimates have a range. Say 20 staff days plus minus 5. Or 10 staff days at 10% accuracy. But usually there is no range specified. You get to see only single and certain values.

Two, all the work elements get the same treatment. There is no distinction made on the uncertainty of the work element and thereby higher or lower tolerances in the estimates.

Same productivity for all resources: When resources are allocated to work elements it is assumed that all the resources have the same productivity. This simplifies duration estimation to division of work estimation by the number of resources. But unless the resource is a machine, you cannot assume same productivity. In fact, human beings are notorious for having different productivity at different times in the project. Needless to add, there are differences in productivity across humans too.

Progressive elaboration not considered: As project progresses, accuracy of the estimates is expected to improve. During the concept phase there would be a wide spread say -50% to +75%. During the design phase the spread would narrow further to say -35% to +50%. This implies that the project schedule gets re-baselined at the start of every phase if not more frequently. But this rarely happens. Once a schedule is base lined at concept stage, it is cast in stone. No re-estimation, no base lining.

Single project finish date: For all the reasons mentioned till now, should not schedule show the project finish date as a date with a range. Say 14-Aug-2010 plus minus 5 days.

But this is rarely the case.

Variations not anticipated: All schedules depict interconnected activities. Variation in one activity has a cascading impact on the schedule. Variation in a dependency outside the scope of your project may also impact your schedule. This is again a well known fact, which largely gets ignored. There is an entire new approach to scheduling called Critical Chain Project Management (Goldratt) which takes care of statistical variations and interdependencies. Even without buying the add-ons for CCPM to their existing scheduling software, project managers can use the concepts of feed buffer and project buffer put under the control of the project manager. But this is rarely done.

No Plan B: Most of the projects have foreseen risks. There is an elaborate risk register containing risk description, mitigation plan, owner etc. But when it comes to plan B, project managers behave like the proverbial ostrich with its head buried in sand. Foreseen risks with high exposure should prompt the project manager to be ready with plan B which would control the damage done by the risk. But one rarely gets to see plan B. Most of the contingency plans talk of communication and escalation like “inform the management” or “inform the customer” in place of a plan B.

So much said and done in the practice of estimations, I will be eager to know your view and experience regarding this topic.

Long before Hrithik Roshan[1] became their brand ambassador and set hearts “Dhak, Dhak, Go”, Hero Honda used to run an advertising campaign – “Fill it, shut it, forget it”. They were referring to the fuel economy of their bike which was claimed as 80 kilometres per litre. That’s why the line “Fill it …”

This popular ad-line popped up in my mind from nowhere, when a close colleague remarked that his project just goes on and on and on.  I began to wonder if the Hero Honda tag line “Fill it …” applied to project management too. I see more people looking at project management as a template filling game. The biggest and most talked about template we fill up is the risk management template. Fill it, save and close it and forget it seems to the practice of risk management.

My observation has been that using standard checklist people do prepare a list of risk or a risk register as described in PMBOK.  But the question is, do we move beyond risk identification and manage risks at all?  So in-spite of all the great intent with which register and plans are prepared, projects continue to fail.  In my view this is perhaps due to two problems

One, the risk register is not integrated with the rest of the project plan.

Two, the risk register remains a well intentioned document but there is hardly any follow up or in the PMBOK parlance, monitoring and control, of risks.

Problem one, is largely an issue of integrated planning. Revisiting the plan taking the risk as inputs is an area that needs improvement. It’s a good practice to show significant risk mitigation steps in the schedule as activities. This ensures that the mitigation plans have an owner and a date.

For example, if the lack of expertise in technology is identified as a risk condition, the corresponding mitigation response would be training the team. One or multiple activities related to training should be there in the project schedule. Taking the same example further, if this training involves hiring a vendor’s services, one should allocate a cost to this which in all probability may consume the reserves or contingency fund.

It is also possible that training once conducted, may not reduce the risk exposure and one will now need a contingency plan or plan B to reduce the impact of this risk to the objectives. For example, hiring expert services on short term contract could be your plan B.

Problem two is the ongoing monitoring and controlling of risk register. It is not sufficient that risks be documented during planning alone. The on-going effort and not just intent to monitor and control, is critical and not doing this is as good no risk management at all.  Remember a risk never closes completely, it just retires. At the same time, a new risk could be just lurking around the corner.

Apart from this, it is possible that the risk exposure of active risks changes that in turn may impact the overall project objective.

Identifying risk triggers is not only useful for monitoring but also assists the manager in defining the appropriate mitigation steps. Risk trigger plays an important role in alerting the manager if a risk is likely to occur. If you are not watching out for the trigger and looking at the actual risk event instead, you may not be left with much leeway to act.

Like they say, chance only favors a prepared mind, just filling up the risk register template and shutting it is not good enough or else we forget about project success.

The maturity of business organizations when it comes to management of IT projects is an area of concern for many CIOs. CIOs lack the visibility they need into project performance, and do not know the magnitude of project delays or the reasons for these delays. Most IT projects fail or are abandoned half-way not due to technical reasons, but largely because of management issues which start from the project selection process itself. There is a need for all to understand that management of IT projects as a service provider (an IT consulting and services company) is very different from managing an IT project as a business organization.

One of the key differences is the approach towards management of IT projects. While the user organization focuses more on the project’s outcome, the service provider’s focus is on project delivery to specifications. The distinction between these two from a project management perspective is not clear, nor is it clarified by industry associations or proponents of project management.
 
There is a need to look at the entire project lifecycle from a business perspective for effective management of IT projects. Aligning the project to business objectives and defining the project’s success criteria early in the lifecycle is a critical aspect. You should look at the success criteria beyond just the efficiency metrics of being on time and within budget. In fact, these are success criteria for the consulting, vendor and contractor community. The user organization should focus more on the business benefits, and not on efficiency of project execution. We are not suggesting that efficiency metrics be ignored, but that they are the responsibility of the contractor (or consultant), and that their impact on the business needs to be measured and controlled.

There is a clear need to distinguish between the various approaches adopted by business organizations or user organizations of IT when it comes to management of IT projects. Moving to a program management process approach could perhaps assist the CIOs and IT managers to appreciate this difference and improve success. Given that most projects have a business case, once the implementation is done, it is important to check whether you have achieved the business objectives. This approach is generally not followed by Indian organizations, so CIOs need to focus on this.

IT project management has moved from being a tactical discipline, and now involves the integrated discipline of program and portfolio management. There is a need to make the IT leaders, the CIOs, aware about this. The use of the traditional development lifecycles (such as SDLC) approach to the management of IT projects needs to change, at least for the user organization.

The future is big

The term ‘project management’ is only a few decades old. Of course many projects were managed before this science was ‘invented’,  and nobody had identified a distinctive need for a management process, still less had they decided what that process should be.

Fact is there were more projects managed before modern ‘Project Management’ was developed than have been managed since. And even today, there are more projects being managed with no help from this science than with it. It could be said, therefore, that its influence up to now has been very small but its potential influence in the future is huge.

One researcher writes in a paper, “Of the 34 important new management approaches and techniques invented since 1960, only 15 were still in use at all by 1995. Their life from invention, through peak use to disappearance, was seldom more than ten years”.

I believe that project management will survive in the long term for two reasons.

1.    It is essentially simple and

2.    It is capable of extremely wide application

The techniques which we now call project management have all been identified and developed over the last forty years. Collectively they are now a proper science, carried out by people who know how to apply it. It is a science, in that it can link cause and effect; it can be taught and learnt.

One way to know the future is to look at trends and if zero people used PM as science in 1960, then it has increased since then and we can safely say its application will continue to increase. Here are some observations to light our path:

•    B K Mundhara, Chairman of Simplex projects, said that we will have more project managers than MBAs in this country

•    In twenty years time, due to the inevitable inertia of human systems, project management has only achieved half its possible volume of application

•    In twenty years there will be 120 project managers for every one there is now – that’s quoting Dr. Martin Barnes in 2002 at a Berlin PM conference

So what will the future look like?

Application of PM will become broader. The application of PM will not just be restricted to physical enterprises like buildings and new products – it will also cover non-physical endeavors like winning an election or a court case, like merging two businesses or bringing together two people in marriage; it could even include introducing the market economy into a former communist state of a country.

Focus of PM application will shift to understanding the whole or towards ‘super projects’, which we recognize today as a programs or part of a portfolio. Every project is carried out for a commercial organization and is a sub-set to that of achieving its corporate goals. Even in a democratic government every project is a sub-project to the project of securing re-election next time. Every project we undertake as individuals is a sub-project linked to the project of securing our own happiness – whether short, medium or long term. We will start looking at managing the super projects too. These super projects will either resemble a program or a portfolio and focus will be on Benefit and Value Management.

Changes in the Science and Tools of Project Management: Both the hard as well as soft techniques of PM are changing and developing fast and can be expected to charge the velocity of change.

The battle of hard sciences

A project is about a group of people collaborating towards a (presumably) common objective. The actual management is primarily about communication and visibility of progress/work that lies ahead for the project members. Directing the executing team presents a novelty when the project and team member competencies are developed on the project itself.

Hard Sciences have evolved from network analysis and critical path method, to advanced heuristics for resource leveling and algorithms etc. But these never quite caught the fancy of real project managers. Also these hard sciences were being pursued by people who found this sort of technical progress fascinating and believed in its illusionary potential.

We continue to produce these network diagrams, Gantt charts etc; but the focus today is on sharing this data. I believe that real PMs prefer to use simple excel sheets rather than any software tools to produce the schedules. I also contend that there is still a future for such hard sciences like scheduling analysis. Hard techniques need to be learned insofar they form the foundation for visibility for project progress (e.g. in cases where details in a plan are not understood by the real PMs. Take a 2500 cr. power project oversight and macro planning achieved with 140 line items).

On the collaboration front, we see a lot of action; it’s more like a virtual communities spontaneously coming together around a project or a group of similar projects. So we have PMs googling, going to social networking sites to find answers to their issues, relying on peers to assist in sourcing people, vendors, etc.

We see project intranets being built and then integrated to social networks for collective knowledge building around issue and risk management.  This is supported by the fact many of the PM tools are adding Content Management Systems to their application suites. Is this a step in the right direction? I don’t know but things seem to developing more in line of what Gartner predicted.

Other organizational endeavors point towards creating predictable environments by way of instilling systems and process culture (e.g. ISO, CMM). We see the continuing labor on illusionary process framework definitions, but real PMs or PgMs continue to work without these.  The way I see it, these efforts have not lead us towards sound Risk Management practices; all the same, we can discern a future for this science coming up. I still find people getting upset if project plans are completely changed mid course but such is reality.

PMOs acting as a central base continue to be a real support for PM acceleration and maturity. I predict that supporting PMs, rather than playing watchmen to the governance team, will lead the battle front by taking more responsibilities as teams become more virtual. PMO reengineering will finally become a reality as PMOs supported by effective integrated applications get real estimations, measurement and mentoring to the Project environment.

All in all, development of the discipline with continue – Program, portfolio, PMO, Change Mgmt, Dash-boarding (people particularly fancy the dancing traffic lights), management by projects, etc.  But let’s keep in mind none of this is absolutely new.

On the softer side

I feel the future is more about certifications, systems and methodologies taking a back seat in order to facilitate core customer needs through involvement and communication, first and foremost.

To this end we see a merger of skills taking place in the marketplace i.e. PM/BA/EA. We are seeing a shift from certification to competency and confidence building. This trend follows the rapidly closing gap between Project Leaders and Project Managers.

We may soon see knowledge profiling of PMs being used to determine the right fit of project profile to his or her profile. My own team created an intelligent tool for learning which gave our trainers data on weak areas of the learners benchmarked with others, but we soon found out that nobody seems to using the data and info available.

We would also like to see the so called sr. leadership team finally deciding to go back to the classroom and align themselves to the PM Way of Working.

Conclusion

So if we practitioners need to remain a part of the future, we need to ensure that the science is continuously developed and at the same time so-called best practices are tested rigorously in order be really useful to real PMs. There should be real knowledge sharing happening.

I often find myself reflecting on the difference between people who meet abstract academic requirements for a PM career and the real world contenders that one encounters on live project environments on client sites. What comes to notice first is the skewed preference that organizations maintain for certified professionals. On the other hand, I discern unvoiced fears and unconscious fantasies related to a project management career.

Many times I have come across good technical engineers who come to a decision point in their careers. They are required to either move to a managerial role or continue as technical champions. To outsiders, the choice may seem to move frictionless in a managerial direction. But there are anxieties connected with this fork in the road. One important fear is that of losing the functional and technical competency.

Also, the budgeting and scheduling tasks related to managerial competencies are known to scare off many technical leads. Of course, choices are also driven by future prospects, newer challenges and experiences.

My advice to technical leads is that they should by all means take their leap of faith. PM is an exciting profession, involving decisions and building networks; and I can say from personal experience that it really brings out another side of personality.

In fact, I wrote a whitepaper recently that goes about the current context of project management as a career in detail. You can download it right here

We live and work in a country which enjoys the third largest PMI membership. Coming right after the United States and Canada, we are part of a national community with seven chapters and more than 12,500 members. The total number of estimated PMP certified project managers in India is 16,000.

Because of its critical role in saving costs and delivering projects on time, there has always been a higher measure of accountability attached to the PM profession. One would think that this would become especially apparent in the current economic slowdown.

But contrary to expectations we are witnessing a downward trend in the growth of the profession. This can be seen especially in the ITES space where PM has been traditionally sponsored by corporate. Training and certification are being cut back.

The answers we are trying to find here must look beyond the ‘rational’ practices of organizations who are having to manage operational contingencies in the current economic climate by cutting costs.

PM in the real world

It is far from controversial to suggest that there has always been an organizational bias towards PMs: They have been looked upon as non-billable cost centers rather than critical resources required for executing successful projects.

Today the trend is getting worse: Abhinav Mayak, Asst. VP Migration, points to recent trends wherein “an artificial need is being created for Program Managers to take Project Manager as well as Program Manager Role at the same time”. This means that technical leads who had earlier been promoted to PM positions based on their technical skills are today being asked to oversee multiple projects within the same organization.

Other than the absurdity of this multiple-hat role, there are significant risks posed by individuals who lack project specific competencies that have an impact on critical thinking and decision making in project environments.

1. Customer engagement and communication suffers due to the unnecessary overlapping of focus areas e.g. program managers need to focus on business benefit enablement and project manager focus on project delivery aspects

2. Costly delays in performance due to sub optimal decision making. This is an outcome of underestimating the management and governance effort required to manage project complexity.

3. Inconsistency in communications due to lack of a commonly shared vocabulary may lead to a loss of credibility among stakeholders.

In this scenario, where project managers are essentially ‘management-agnostic’ themselves, I am concerned about the kind of crash and burn scenarios Indian outsourcing companies will face while operating under the lack of PM bandwidth.

On the other hand, let me present three advantages that organizations can enjoy when they employ project managers who are familiar with formal project management methodologies

1. Project teams will be aligned to the needs of the stakeholders when the project manager understands the decision making that goes with the business side of the project.

2. Teams will be armed with the ability to resolve progress and performance issues with use of proven processes and methods and will not have to leave project outcomes to chance and heroic efforts

3. By bringing in transparency and reliability on the project status, sponsors will benefit from a clearer picture of project progress and the consequently the project will face fewer conflicts.

The road ahead

Another senior PM I spoke with, Ruchikar Dalela, pointed out that “this is a self-critical period for the PM practices of the various Business Units. The delivery management teams are expected to show visible improvements in the management of projects”.

Hemant Arora, Product Champion, reminds us to use measurement metrics to show “that PM was not only necessary, but it was vital to ensure that profitability was assured in wafer-thin net projects by proper PM”.

Training programs must also be seen as specific skill-enhancing investments. Proposals will need to need to articulate concrete details on the true impact of the learning. It would be needed to show current gaps in PM competencies and how the proposed investment would realistically bridge these gaps, and what improvements in margins would result by bridging such gaps.

This is why in professional circumstances, I prefer processes. A process is an entirely different animal to kill.

COMING TOGETHER ON PROCESS MATURITY

In circumstances where time and money are limited and goals need to be articulated in specific terms, planners and executors come together on several methods and theories and agree to some commonalities in terms of outcome; they also face a common need to forge a level of uniformity in processes at global levels.

This is where Project Managers come together in their efforts to define Project Management maturity. The term, I believe, has unjustly been passed around as a managerial buzzword. Let me make it clear as to what maturity exactly means:

Project Management maturity is the progressive development of an enterprise-wide project management approach, methodology, strategy, and decision making process.

I find Kerzner’s model still relevant today. This model talks about the levels of Project Management maturity in an organization. These are:

Common Language: At this level, the importance of project management in the organization is recognized.

Common Processes: This level is where organizations realize that common methodologies and processes are needed for replicating success from one project to another.

Singular Methodologies: At this level, the development of singular methodology rather than multiple methodologies for better harmonizing and process control is realized.

Benchmarking: The objective at this level is to improve own performance by comparing with others globally.

Continuous Improvement: The organizations begin benchmarking against other companies.

A good colleague of mine who is now a well-respected program manager once shared his odd sense of ‘destiny’ about becoming a project manager. He said he always knew he would grow up to be a project manager. A son of doting engineers, he was brought up to respect the clockwork rhythms of work, study, and play that quietly structured his adolescence. Awed at times by the sense of organization his father displayed even in times of crisis, he too started finding in himself a hunger for a higher sense of order in his life. His records were tagged and numbered; his assortment of Mad Magazines archived according to date. He also claims to have invented a new system of storage and classification for his family’s extensive photo collection going back two generations. So when he was chosen amongst his peers to lead his first retail project in Karnataka at age 23, it only seemed a natural choice to both himself and others around him.

The expectation in this scenario is that ownership by the team of the planning, execution, and review of both the product and the process leads groups to a high level of self-directed performance. This performance is then sustained through continuous reflection and improvement. This change in the dynamics of leading projects often excites nervousness on the part of project managers, because they begin to wonder what their role will be if they’re no longer directing a team’s efforts.

When I met my friend recently, we ended up discussing this substantial change in the project manager role. As expected, he had anticipated my questions and shared what he thought was a possible approach to this unique dilemma.

• There has been a warranted shift from the command and control position that traditional project managers need to come to terms with.
• Mentoring, guidance, and facilitation are now the key roles demanded from project managers in the software domain.
• The most difficult obstacle to overcome however is the fundamental attitude to change itself. Traditional plan-driven projects already have features and tasks defined to implement the product. Resource planning then becomes a matter of identifying roles and inserting resources to fit those roles into the project schedule. But agile development is fundamentally open to changes in requirements. With customers giving feedback at the end of each iterative cycle, there is no need to stick to a “big design up front” scenario.

Skeptics should take note that there exist successful cross-functional teams made of developers, testers, analysts, technical writers, architects who are accustomed to delivering highly specialized software products in an informal yet effective fashion.

I would really like to know what you think about implementing agile methodologies. Do you agree with this assessment of the changing role of project manager? If you want to share your experiences in agile management, here’s a good forum to do it.