Evidence driven Project Management competency improvement

In Large and medium organizations, the competency improvement needs are identified using a top down approach.  This approach  helps in taking the organization to the next set of competencies, based on the process/product/technology road maps and assessment of the current competencies.  The needs so identified  are addressed  through the competency improvement of the individual employee, while addressing his/her career preferences. While this is usually helpful as a first step and results in a set of trainings, this  may not help address the deficiencies fully.  I take project management as an example and present an approach for assessing the competency gaps and tailoring an improvement solution that can be driven by Project Management Office (PMO) or equivalent role.


As we know when a  software projects is challenged, root causes are identified and a solution to address the same is implemented. This is more likely to be adhoc and may fail to address  deficiencies holistically. PMOs can  follow the structured approach below as a better alternative.

1) In the recent review period( last month/quarter/year), identify the challenges faced  by each project,  assigning one or more of  the 22  anti patterns (examples: Detailitis plan, Road to Nowhere, Micro management) compiled and  analysed by Pedro Silva et.al, "Software Project Management Learning from Our Mistakes", IEEE Software, May/June 2015 pp 40-43.  This could be tailored as appropriate.

2) Perform a statistical analysis on the anti patterns to identify the top  anti patterns.

3) Identify the impacted roles and root causes.

4) Based on the above, identify the solution from one or more of the suggested solution types (process/role/technology/training).

5) Work with internal/external solution providers to implement the corrective actions spanning process redesign/training/coaching  etc.

6) Repeat the above steps to see whether  the solution  has yielded results.

In my extensive experience in industry, the first and last steps are  not given due importance with the result that the competency improvement remains weak at best. Do you agree? Share your views.

Cloud based project management

Awareness of Project Management and its impact on business success  is increasing day by day, thanks to the advocacy of Project Management Organizations and also adverse publicity in the media about challenges in  delivering large and complex projects. Many companies have set up or planning to setup project management offices to help improve Project management maturity with appropriate focus on process, people and tools.

A project app(Credit:BiH via Commons)

Simple project management tools over the last decade have become more powerful  to be able to support project portfolio management. Another trend is that more tools are becoming available on cloud, which promotes  access to all project stakeholders  wherever they are physically.  Smart phone support is also increasing so that people can still access their projects even if they are on the move.   Integration of Social media like features and integration with other tools like email enables people  to collaborate better.


The above trends will enable more and more traditional companies to become better at project management as they move from ad-hoc and non Internet based processes to Internet based processes. While proprietary software like Microsoft Project 2013 has advanced features, several competitors are emerging,  offering solutions at various price points.  Traditional issue management software like Bugzilla are also evolving  to support  scrum teams,(Scrumbugz) while several collaboration tool vendors and Web 2.0 are offering enhanced support for project management.   New tools, developed from scratch to support agile development needs  are also available (Trello).

Supply and demand for Project Management skills in India

The recently released report by  KPMG-PMI on  Schedule and Cost overruns on Infrastructure projects in India  is interesting to read. The summary is that lack of qualified project manager and other engineering resources along with  external issues such as regulatory delays,  site handover, poor scope management are the major causes for Schedule overrun.   Poor resource,  procurement and scope  management are identified as some of  the major issues causing cost overrun.  As per the report, these  can be addressed easily  by improving the PM capability of the organization.

Credit:KPMG In India & PMG Study

Lack of skilled manpower, impacting schedule  is felt deeply in  Coal, Steel sectors followed by Power, Roads&Highways and then by Railways, Telecommunication. Scope creep, Design change, Environmental safety are major causes affecting cost overrun in Steel and Civil Aviation sectors. Telecom sector seemed did no have cost overrun.

86% of survey participants have  expressed the need for  PMOs to address the Schedule and Cost overruns and some have already established an internal PMO/engaged an external PMO. 56%  have reported use of Risk Management practices and  76% stated that their Risk management is effective.  Therefore, the conclusion that  poor risk  practice could be the reason,  based on the fact that 53% are behind schedule and 34% overspend seemed a bit surprising, though the report  covered various issues that impacted the project in the preceding chapters.

Taking the case of construction sector, the demand for project managers is estimated at 70,000 in 2010 moving to 2,27,500 by 2022.  Supply was projected to be 1,20,000 as per the twelfth five year plan. As the number of civil engineering seats have not grown well in the past(possibly due to the lure of CS/IT), it was recommended to introduce PM as a subject in Civil Engineering.

The report also provides a set of recommendations to expedite infrastructure projects. Three tier PMO (National,State, Implementation level) and setting up internal Project Academy in each organization as was done successfully by  IT industry are some of the recommendations. The report also had few case studies on how different organizations are dealing with the challenges. While the report looks good overall,  it could have been improved by use of visuals from Indian construction scene, rather than some stock photography of western country infrastructure projects. 

When I joined  engineering 29 years back, I opted for Electronics & Communication Engineering, which was least popular. I was glad that I  was able to land a government job through campus placements, when I finished the course. My civil engineering friends  had a hard time getting jobs. Some of them moved to Computer Science(CS)/Information Technology(IT) for their  post graduation course and  had made a good career subsequently.  Looks like what is required is the reverse now, as there is a glut of CS/IT engineers, many of whom could be easily trained for Project Management through short term bridge courses, which the report authors  seem to have missed.

Dealing with poor reliability issues

While a project faces several issues during its lifecycle, poor reliability issues are  critical as these can lead to failed projects. These are also difficult to resolve. If the functionality does not work, then it is possible to find the root cause and implement corrective action. If the problem is intermittent, then it is a big challenge to  even diagnose the problem.

"Blue Screen of Death"  (Credit:Masem Via Commons)

I would like to highlight two  instances of poor reliability  and the corrective action that helped.

In the first case, a Personal Computer (PC) running Microsoft Windows 95 was used along with an custom built add-on card to  provide interactive audio video services over cable television system.  The services were disrupted sometimes and the reason was that PC crashed.  The service could be restored only by rebooting the computer. As there were several software components,  a careful check of the  application software  did not reveal a problem, the fault was assumed to lie with operating system software. The short term fix was to detect the PC crash  and provide a hardware trigger to reset the PC. The long term fix was done by moving to an embedded hardware  with reliable real time operating system.

In the second instance, the PCMCIA modem that worked with laptops for Wireless Internet connectivity  was used in an embedded environment for transferring equipment health data.  During the tests, it was  found that the modem operation was intermittent. We tried to reproduce the error in the laptop environment apart from contacting the vendor for advice.  The vendor suggested using a new version of the modem cards. After extensive debugging with alternate wire-line modems, which had high reliability, we traced the problem to  bugs in the TCP/IP stack supplied by the real time OS vendor.  As these problems surfaced during the later part of project, this led to crisis situation, requiring fire fighting actions which are costly and detrimental.

In both the above cases, the issues resulted from trying to use Commercial Off The Shelf  (COTS) HW/SW for aggressive time to market  and low cost product needs, while  ignoring the reliability issues. By focusing on the reliability requirements  during the requirements phase and ensuring appropriate design choices as well as early prototyping to find out any reliability issues, projects can handle such issues effectively.

Making sense of state of Project Management

Several professional and consulting organizations  publish surveys of  Project Management  every year.  I used to be a  big believer in the past  but became skeptical  in the recent years, as there seems to be weaknesses/bias  in the survey design, administration and analysis.  I give couple of examples  to  support my change in belief and suggest the need for  organization relevant surveys.

Standish Groups' CHAOS study is famous for  painting a bleak picture of software due to high rates reported in its survey findings. In 1994, it was reported that  a shocking 16 percent projects were  successful, another 53 percent of the projects were challenged, and 31 percent failed outright. While the numbers improved in subsequent years, still the  issue highlighted remained the same that software projects are out of control. In 2010, J. Laurenz Eveleens and Chris Verhoef of  Vrije Universiteit Amsterdam published "The Rise and Fall of the Chaos Report Figures"(PDF opens in a new window), which highlighted the major flaws in the study and its impact based on an independent database  of Projects while following the methodology of Standish Group. The  research concluded  that the Standish definitions of successful and challenged projects  are misleading, one-sided, pervert the estimation practice, and result in meaningless figures.


Recently I have come across PMI 2013 Pulse of the Profession report (PDF opens in a new window) and read with interest the claim that  organizations risk, on average, $135 million for every billion dollars spent. Low-performing organizations, however, risk 14 times more money than their high-performing counterparts, Talent management, Standardization of practices and tools and Strategic alignment were identified as key focus areas to become high maturity organisations, which have reported 90% project success. In order to investigate the survey in more detail and I accessed the question wise responses in Pulse Interactive Report (accessible to members). 

Based on my preliminary analysis, I  found that the definition for success used for the survey is delivering the project's initial scope  within the   initial time and budget estimates. When I looked at the reasons for failure, I found  "Overall Change in organization's priorities" and "Inaccurate requirements gathering" as top ranked. This is not surprising if the triple constraint is the  one driving the survey design. In order to apply the findings, the question that needs to be asked is whether your organization is still  following the triple constraint.  The PMBOK 4th Edition leaves out the  definition of  the project success. In the fifth edition it is defined  in relation to last baselines approved by authorized stakeholders. As the survey participants may not have consistent idea of project success, the responses may not be consistent. The survey findings need to be taken with a pinch of salt, if your project is exploratory and software intensive.

As we enter the last quarter of the year, this is right time to assess the project performance  during the preceding twelve months within your organisation with a custom survey designed to identify the strengths and improvement areas of interest  to plan for  the next  year. Even if the number of projects is small, the results will be much more relevant and useful.

What has been your experience with relating to the surveys and also in house surveys? Please share the same.

Managing Cognitive biases

I picked up Rolf Dobelli's book called "The art of thinking clearly" recently at a book store.  After reading several chapters, I liked it very much, as  I can relate each chapter to my life own experiences. As an example, consider Reciprocity bias, which plays out usually in our lives. In one example,  people are triggered  to  donate to Charities when they receive a small  free gift. I have been a donor to few charities. But the sight of a free gift mostly weighed my action.  I was able to break out of this bias, when I became aware of this bias,  and was able to stick to my  specific objectives related to my donations.

Rolf's book  lists 99 biases, though it does not aim to be comprehensive. The main point from his book is that we are wired to be intutive and it takes lot more energy to think well for making a decision. He advises us to use the intutive decision making for  the circle of competence and use the checklist  of cognitive biases for any decision with major consequences. Of course, we need to be aware of the  feature positive effect (which is one more bias), when using checklists, as we give more weight to what is on the checklist than to what is not.

How can we use this to be better at  our professional roles.  For each decision making  situation it is advisable to look for one potential bias from the book and then use the first level cross references listed at the end of the chapter for other biases. So when we are submitting a project proposal, we know that we may be over confident in our estimates. So look up over confidence in the index. which leads us to  Overconfidence Effect and then to Illusion of skill, Forecast illusion, Strategic misrepresentation, Incentive Super response Tendency and Self Serving biases cross referenced from that chapter. By reviewing these, we may be able to make a better decision.

In an organization with mature processes, the decision making step would be preceded by various information gathering and analysis steps, involving more number of people, which could act to counter the cognitive biases to a large extent.

Oppportunity Management

During my recent talk on Risk Management Best practices, I focused on applying standard risk model, which requires identifying the event  and its impact explicitly along  with their respective drivers(causes). Separate identification of drivers enables  preparation of prevention   and contingency plans. A participant asked me a question of how to manage opportunities,  events which  reduce the time, budget for a baselined project. As per PMBOK,  opportunities are managed the same way as risks. A detailed risk and opportunity management process applicable for a city council is a good read to understand the application of this concept. In IT/engineering projects, Opportunity Management  is not so common. In this blog post, I explore the Opportunity Management and share few thoughts that I hope are practical and useful in practice.

Usually projects are taken up to address an opportunity such as addressing a underserved customer need, acquiring new skills, establishing a platform/IP that can be leveraged for a long time. This means that entire project is actually an opportunity management at the level of organization's portfolio.

Estimates for complex projects involve great deal of uncertainty. These are generally optimistic given the excitement around new project and general human optimism, despite the use of robust processes. Once the project is approved, the focus is on delivering  the project as per expectations while managing  threats.  Given a good system engineering approach, work is planned and executed to deliver as per expectations. Multiple options with respect to schedule/cost are explored as part of Project Management before baselining. This process  implicitly manages the opportunities to reduce the schedule/budget.

Due to change in customer scope or technology advances,  it is possible that certain options which were not explored during the project proposal/planning phase may become desirable for long duration projects.  At the same time, such options will not be without their share of risks. As an example consider that an enterprise mobile  application was planned initially for  one category of mobile Operating system, During the course of development,  the push for Bring Your Own Device (BYOD) made the need for supporting multiple mobiles became a pressing need. Then the opportunity of utilizing  a mobile OS neutral platform, which allows seamless targeting of mobile app to  other mobile operating systems become attractive.  In such a  case, it is advisable to pursue such  opportunities if the cost/time benefit after considering the risks associated with it  is beneficial.  If not, then it  would be more useful is to route such ideas behind opportunities through innovation pipeline of the organisation/group.    Once the idea passes through the innovation pipeline, the technology developed could be utilised in  future projects.

So in summary, my view is that opportunity management is implicitly practiced at the project level. It is more practical do it explicitly at the portfolio/organisation level. Share your perspective?
 

Benefits of Risk Breakdown Structure for Portfolio management

One new concept in PMBOK 5th edition is called Risk Breakdown Structure(RBS). This is a powerful concept to improve the risk management practice in the organization. Let's explore this in more detail in this post.

Graphics Credit:Andreas Plank 

During the postmortem or retrospective, lessons learnt from the project are captured including the experience with the risks. Usually this document in the form of a word document or Excel register is stored in the repository. If an organization has an efficient search engine for the repository, these documents may become useful for future projects. Though the tacit knowledge of the team is captured in the document, it is still not effectively used, because it is not in structured form.

The creation of Work Breakdown Structure(WBS) is critical for Scope definition and subsequent project tasks. As WBS is a hierarchical depiction of deliverables at various levels of granularity, it is useful for planning and reporting to various stakeholders. RBS arose from the need to organize the huge list of risks identified in a project. As its name indicates, it is also hierarchical organization of risks in various categories. If we look at a software project,(As per Dorofee A.J et.a's 1996 book "Continuous Risk Management Guidebook" quoted in Dr. David Hillson's article "User Risk Breakdown Structure to understand your risks", 2002) the sample organization at the first level could be product engineering, Development environment, project constraints. At the second level product engineering could be broken down to life cycle phases, Development environment could be broken down to development process, management process, work environment. Similarly the project constraints could be split into team, contract, and interfacing stakeholders.

RBS can be used instead of traditional risk check list for risk identification. Or after the risks are identified by other methods, these can be organized into this structure. Once this is done, insights such as dominant categories of risks can be gained. Additional risk identification sessions can be undertaken based on RBS to make the exercise comprehensive. Similarly the hierarchical nature of categories allows appropriate focus at the various organization levels. If all projects follow this, portfolio risk management becomes easier, as the risks can be aggregated in relevant organization wide categories and handled. At the closing of the project, populating the risks lessons learnt as per the RBS in a database makes this knowledge much more useful for future projects.

Did you use RBS? Are there any better methods? Share your thoughts.

Changes in PM Challenges

Agile Focus (Image Credit:Kfp1921 Wikimedia Commons)

 

 

I attended this year's Project Management Practitioners Conference(PMPC-2012) conducted by PMI, Bangalore Chapter  on 14th and 15th Sep 2012.  Of particular interest to me was the panel discussion on "Emerging Trends in Project Management" in which challenges facing the PMs  and the skills being demanded are usually presented. The panelists were Gautam Rao(GE),Naresh Babu K (HAL), Prabhakar Kandaswamy(Vmware),Prasad Kasinathan(Motorola) and Ramam Atmakuri(Cognizant).  Few trends that were discussed include

• Portfolio Management
• Product Management
• Global Program Management/Virtual environment leadership
• New tools for the new generation
• Shortening life cycle driving adoption of Agile methodolgies 

The skills required from the PMs are to be a visionary, anticipate change, manage interdependencies and suggested best practices include leveraging the face to face meeting opportunities to the maximum in dealing with Virtual environments.

I also attended the 2007 edition of the conference. I would like to recall the challenges in Project Management that were captured in a panel discussion, in which Parthasarathy N.S, ( MindTree)  Narasimham R.V, (Ryzhom)  Srikantan Moorthy, (Infosys)  S.R. Yogananda,( Rotary) and   Arun Sahu, (Central Excise & Service Tax) participated.

• Shortening life cycle
• Performance on Non functional requirements
• Impact of Project on Organisation performance (beyond  the triple constraint model)
• Virtual teams

The skills required from the PMs are  flexibility, conflict resolution, PM competency, teamwork and  best practices include having checks and Balances, stake holder management, Input chain management, hiring MBA's, better knowledge management and effective use of Email.

If we compare the two summaries presented above, we find that PM landscape has seen the focus move from Projects to Portfolio/Product space, while the pressure on shortening life cycles and challenges of  virtual teams continues.  The PMI is  responding to the trends by focusing on Agile(PMBOK 5th Edition,  and  PMI-ACP), developing more customised extensions to PMBOK (Software extension is in the works in colloboration with IEEE Computer Society).  Do you agree with this summary? Share your thoughts...