PMI ‌‌‌‌Bangalore Chapter's Footprints 7th Anniversary

I attended PMI ‌Bangalore Chapters' 7th Anniversary session of PM Footprints at Hotel Atria on 9 Nov 2013.  The event included a session titled  Agile development: Cultural Nuances by Sivan Menon, CTO - SW, GE Healthcare India, John F Welch Technology Center and  another one titled Meandering Musings by Siva Vajjhala, CEO & MD Advanced Business &Healthcare Solutions India.  It is a wonder that a program of this nature where a speaker presents on a topic  every two weeks  had recorded a total of 213 sessions without missing a beat over seven years.  The speakers who contributed to making this happen during 2012-13  were also recognized with a certificate and a small gift on the occasion.  I also felt  happy to have been a speaker for the session on Risk management few months back.

PM Footprints Logo

The event  provided an occasion to get to know Murali Santhanam and Vijay C Paul, who have taken over as President, Secretary respectively of PMI Bangalore Center.  BG Jayaram, past President thanked Amar Bhaskar for the program initiation and wished that it would evolve  to support virtual sessions and failure stories which will be of great help for professionals. The "Recognition of Excellence" award received by PMI Bangalore Chapter from PMI was presented to the audience by Vijay Paul. 

Sivan explained how Software development evolved over the years towards  Agile development with the Internet era. He explained that  human resource processes needed to change to support this transformation. He said that simple techniques like  empowering the teams to participate in selecting new team members or using 360 degree feedback for  appraisals are helpful in the cultural change. He spoke  about how he has seen Agile work even in a well regulated domain like medical products, by engaging more with customer has been beneficial and how these can be extended to other industries.

Siva focused on more down to earth matters like the common pit falls in pre-sales processes and use of human intelligence and triangulation to identify potential problems in early stages can be helpful based on his experiences at Mindtree. He also talked about  group dynamics and introduced the dangers of group think and group shift and how they can be avoided by  simple techniques like step ladder technique where individual group recommendations are combined  in a sequential manner with those from other groups.

During the Q&A session, T. R. Anand, Management Consultant & Advisor  opined that organizations need to develop skills to handle unstated scope, which may lead to risks/opportunities.

Rakesh who served as the anchor for the program and other speakers made the entire evening entertaining by humorous remarks.

   .ీామ

T

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).

Dealing with black/gray swans

A black swan  in a complex system, as popularized by Nassim Taleb  is a metaphor for a large impact, rare event that comes as a complete surprise to all stakeholders. A gray scan is a metaphor for an event with large impact  with very low probability, with the result that most stake holders ignore.  Usual risk management practices deal with known knowns where the adverse event occurrence as well as impact are both predictable.

Credit:Arjuna based on Marek Szczepanek(Wikimedia)

As the world is more digitized and interconnected and is dependent on large complex information systems,  stakeholders are increasingly facing  black/gray swans.  The impact increases as most of these are unique, connected and closed systems like mobile phone network, power grid and applications based on Internet.  The glitches and shutdowns are regularly chronicled in IEEE Spectrum risk factor blog.

In an excellent paper "Management of Hidden risks", IEEE Computer, January 2013, (paywall)  the author Kjell Jorgen Hole recommends few suggestions to deal with gray swans based on the experiences from the outages in Norwegian Mobile phones, Electronic voting systems, and bank payment authorization systems based on public key infrastructure. The suggestions include  identifying the dependencies between systems and ensuring that the system can continue to run for a minimum period by using back up system (for Mobile networks), providing an alternative mechanism (like paper based ballot for e-ballot) and alternative authentication mechanisms and confirmation messages (for banks). It is useful for project/engineering managers to learn from these and  plan for  dealing with gray swans.

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.

Customer focus in product development

Goal of any business is to provide  product/services that delight its customers. When designing a new product/service, businesses put lot of efforts  to understand customer needs.  Interviews, Surveys, Focus groups are some of the techniques that are used. While the insight of  the development team, if they also happen to be the customers as in the case of  IT products in Social media space may be helpful, real test of the new product/service happens when it is deployed.  If the product is entirely new, customer may be ignorant whether a feature would be useful or not or may not  be able to express his needs clearly. In such a case use of prototypes and evolutionary development  would be helpful. In this post, I would share few examples of customer focus and how they can provide unexpected benefits as well.

First let us consider the production of digital magazines. As we all know digital magazines try to mimic the look and feel of print magazines. So they provide two up views, nice animation of page turning, but as the resolution of most computer monitors is poor, they provide  zoom levels of one or two, which may not be sufficient.  One new vendor (Example: Digital DNA epaper) has come up with a feature where the selected article is provided in HTML, where the  text size would be much easier to read.

As a second example, let us consider the publishing of podcasts. If this is just an audio file, it needs to be downloaded and played. Alternatively it can be streamed.  As our rate of reading is much faster than our rate of listening and also provides opportunities for skipping content,  providing a transcript of audio would benefit customer a lot. (Ex:Steven Cherry's Computing podcast on IEEE Spectrum)  It is also helpful if the accent of the presenter is  not familiar to the customer.

As a third example, let us see how the audiovisual recording of conference sessions are being served. Most of these are just served as streaming video files, may be some times with timeline table of contents.  The presentation slides used by the speaker usually are not mixed or provided with the video.  This product will delight the customer, when customer can access the content in different ways like read the slides, read the transcript, listen to only audio and  view the video recording. (Example: GUADEC 2013 Conf sessions by SuperLectures)

While providing the multimodal features is a challenge because of the additional effort needed,  there will be significant benefits in terms of attracting more customers. Not only that, providing the contents in multiple formats particularly text formats also helps the content accessible to search engines and thereby increase their accessibility.

Tool integration Kaizen

As per Wikipedia, "Kaizen" (改善) is   Japanese for "improvement", or "change for the better". It  refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, and business management.  This word  became popular with Toyota Production System, though the word originated when Americans started training Japanese with a program called "Training in Industry" post second world war.    

Kaizen  is started when a problem is noticed in an operation. It is also used  as a first step in implementing productivity improvement initiatives in an organization. As team members can easily participate in the idea generation and implementation, this initiative is easily adopted.  Though IT tools are widely used in  organizations
, there is usually lot of manual work required when putting together  progress and/or review reports.  The improvement required may not be priority for the organization, hence some sort of a kaizen is called for.  I illustrate the same with a simple example from Earned Value measurement exercise.

When I worked as a Project Manager for a product development, we used MS Project for planning and tracking. For Earned Value computation for a task we need PV, EV and AC. PV stands for Planned value, i.e the amount planned for a task (it is expressed in person hours rather than  money, as the project was contracted based on a Time and material model). EV stands for Earned Value, which is an indication of the progress on the outcome of the task. AC is the Actual cost  incurred for the task.  Effort spent by team members is captured in a separate tool, which was developed to cater to the project and its life cycle phases. User's entries with respect to task are also captured in a field.   As a team member can work on multiple tasks and a  task can be worked on by mutiple team members, it is not possible to find the actual effort that was incurred for a specific task. Asking team members to update the data in both tools led to consistency issues.  So the tracking consisted of more of the variance in the planned effort versus actual effort at the project level.

The kaizen that I proposed and implemented  consisted of adding a custom field(task number) to Microsoft Project and using that to map the team members efforts in the time sheet tool, by having the team enter the task number followed by the description of the tasks.   Microsoft Excel was used to process the exported  time sheet data  and MS Project data. The updated date was finally imported into Microsoft Project. This along with improved definition for EV of  a task  and manual updates from the members allowed us to compute Schedule Performance Index(SPI), Cost Performance Index (CPI) metrics at a task level.  Traffic light representation of these metrics made the project status more visible to every one thereby improving the tracking and ultimately the project performance.

Modern tools provide support for tool integrations or provide open interfaces.  Do take a look at the various tools that your team uses and identify how the lack of integration is impacting the work. Start an integration  kaizen to improve the productivity. 

Managing digital Subscriptions

As professionals, we all need to keep up to date with industry knowledge through professional and trade publications. Few years back, the paper publications are the norm and one can always file them and study them when one gets free time.  Nowadays, institutions have started offering digital publications, with advantage of lower price and fastest delivery(over Internet) and  availability in multiple formats.  Unfortunately for people habituated to reading paper copies,  switching over to electronic magazine does feel cumbersome. While magazine publishers have tried to mimic the feel for a paper copy, by providing 2 up views (two pages view),  giving animation of turning a page, user has to play with zoom settings and scroll settings  to be able to read an article.  I feel most comfortable when I can read the article in HTML format, though I have to click on Figures to be able to read and understand them. Unfortunately not all publishers provide HTML views of articles (IEEE is an exception)

Feed icon

Another aspect is about  keeping up with latest issues of magazines . Institutions send out an email when the new issue is ready. You may file it in a 'Read and Reference folder'. If you subscribe to several magazines, websites, blogs, it becomes very difficult to manage the flow. Recently I switched over to using Feedly  Newsreader as a way to  get to the feeds  from all the sites of interest.  It makes it easier to browse the feeds  and read articles of interest. Still you may need to select some for later reading, in which case, you can use the newsreader 'save for later' feature.

BTW, if you would like to keep up with updates on my website,  you can click on the feed icon on the top left of my website and add the URL you get into your newsreader.  


The applications also  allow you to share articles of interest using social media.   Do you have any other tips? Please share by commenting on the blog or where you see the reference to this in Social media. Thanks

Making Project Inquiries effective for knowledge transfer

Every project team would like to learn from their past experience and use that learning to improve the future. Other project teams also would like to learn from the experiences of past projects in order to do a better job.  While each project is unique, there are common characteristics among a set of projects undertaken, with respect to technology, client, end customer etc that can yield useful lessons.

Project teams usually conduct these inquiry meetings at the end of a phase. In this, the relevant metrics for the previous phase are presented and the reasons for successes and setbacks are gathered through brain storming and captured in an document. The templates used for the project inquiries are  usually not appealing as they simply consist of tables and numbers. Usually, the document is put into a repository and  it  is not likely that the lessons learned would be used by other teams. I suggest few practices  that will increase the value from project inquires.

• Compare actual Productivity metrics with the estimates used for planning and update plans for the next phase of work.
• Capture the lessons learned  in the form of an engaging stories with pictures, drawings and  have it shared on-line and off-line internally.  Consider the structure for capturing these stories by  assessing the project from project management  phases (Initiation, Planning, Execution and Control, closure) as well project management knowledge areas (Scope Schedule, Cost etc) .
• Encourage the project team  to also share the findings in appropriate industry forums as these are great opportunities  to learn from outside the organization.

Benefits of Open source practices in corporates

Having had experience with open source and  corporates, I am interested in exploring how open source practices are helpful for  corporates. I share couple of  examples and  ideas on how organizations can adopt these practices.

Photo:Auregann

The first example I share is about experiencing autonomy. Motivation is  one of the keys for accomplishment. While Industry typically utilises monetary and other rewards for motivation, Open source does not offer much scope for it. So what motivates Open Source Volunteers?  It is autonomy, the freedom to contribute to an area of interest. By being an active volunteer they may get recognition in due course. Fedex days, a 24 hour hackathon, which gives  freedom for employees to build a piece of software that delivers benefits is a practice that has caught on in the industry.

The second example that I share is about having a open tool eco system which includes version control, issue tracker, mailing list, forum,  task management, and wikis. etc  to support  software development and making it publicly available inside the company for other colleagues to participate. This is called 'inner source'.  I came across an excellent paper "Open collaboration within corporations using software forges" by Prof. Dirk Riehle et.al, which described the analysis from SAP, Microsoft, IBM,HP.  Upto 7.5% of relevant employee population participated in these initiatives in 10 to 18 months of launch. The benefits of these include attracting volunteer and motivated contributors, better quality, utilisation of experts, better support and easier transition from Research to Product engineering.

Fedex-days can easily be tried  by Indian software or engineering companies of any size. While 24 hours may be good enough for simple ideas to be transformed to working demo,  other ideas may require second or third instance of  the initiative or  optionally can be taken up by the research team.

For Inner source,  a company or its business groups  with 100+ employees would have better chance of success. As innovation becomes key for excellence,  these practices can be great enablers.

How does open collaboration work  in your organization? If you need help or would like to discuss more, do get in touch.

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.

How visual is your Schedule?

Recently I attended the annual Wikipedian gathering called Wikimania in Hongkong. One session I particularly liked was called Imagine Wikipedia in 2022. The lead presenter shared the forecast  that  Wikipedia will become personal, linked up and Visual by 2022. We are increasingly living in digital world and visual content is becoming more common in  our social media circles.  That set me thinking about the nature of use of visuals in Project Management.

When I was the program manager several years back, I remember making a huge schedule. Even after printing on A0 size plotter, it was too detailed  and relating the gantt chart to the task text is  difficult, as connecting lines spread across vertically or horizontally. I reverted to  use of digital  schedule and emailing the same to project team, with occasional display of printed schedule for major meetings. The closest way to make a presentable schedule was to show the summary tasks along with their status. Later I switched to  detailed schedule till the  upcoming milestone and a gross schedule for subsequent tasks, which helped bring down the complexity.

Edward Tufte, who is notable for his  thoughts on Information Design and data visualisation, has a page on  Visualisation of Schedule on his website   which is worth reviewing. He recommended  presenting the big picture and then showing the detailed view of the relevant segment.  Microsoft Project  never implemented it as an off the shelf graphic feature. Some software add-ons or independent software were realized  to support this requirement.

With the availability of Smartphones, the problem severity increases because of the small screen. The availability of touch screen can help in  providing the necessary detail for the selected part of the schedule.

The agile camp side stepped the problem by introducing short time boxed sprints which has small number of tasks. The task status is sometimes represented  visually using Kanban cards. 

How do you handle complex schedules? Share your views.

Improving the effectiveness of Project Health Check

Project Managers  are critical resources in any project driven organization. Usual career development plans  focusing on training programs are not sufficient for project managers.

Photo: Mashup of Images from Commons

Improvement opportunities for Project management arise from different stake holders such as customers, manager, team and also from activities such as  quality audits/ retrospectives.  These improvements are identified at a surface level rather than from a detailed in depth understanding of practices. Usual management review process tends to focus more on project rather than the project manager as an Individual.

Project health check is a practice, where an experienced project specialist  works with Project manager and uses an  assessment methodology to assess the project performance.  This also identifies opportunities for improvement. Where the improvements relate to the competencies of Project manager, mentoring by the specialist will be of great help. While the specialist can be drawn from with in organisation, an external specialist will be more effective as such an individual can work without any bias and constraints on time. For mentoring to be effective, both  the management and project manager need to have faith in the mentoring process and the external specialist.

As organizations are forced to  move from time and material business models to fixed price/outcome based models, due to the business dynamics,  the expectation on PMs are increasing. Institutionalization of  Project health checks and mentoring will be a worthwhile investment.

What has been your experience with mentoring of project managers?

The importance of estimation procedure for traditional projects

One of the major causes for Project delays in Engineering/IT projects is usually poor estimates.  A careful examination of estimation practices is required  to assess whether estimation is the real cause. If the estimate is single point  and only done at the proposal stage of a long duration project,  the estimation will necessarily be poor. 

Steve McConnel's Software estimation book presents 118 tips for improving the estimation after exploring both the art and science of estimation. If I have to pick one best tip, it will be Tip#77, Develop a standardized estimation procedure at the organization level; use it at the project level.

Estimation procedure makes it practical to implement  the cone of uncertainty, which is nothing but how the accuracy of estimate is improved by appropriate selection of  estimation methods and their inputs. Considering NASA SEL estimation procedure example, the project at the end of requirement analysis uses the number of subsystems as input and thumb rules for size and effort estimation along with uncertainity range of  -43% to 75%.  The rule for estimation at end of implementation is to use the current size, effort expended and schedule expended to derive new estimates for size, effort and schedule with an uncertainty range of -9% to +10%. Determining the procedure is difficult, as the  historical data of projects need to be analyzed  and transformed into thumb rules.  In my career, I  did this for few projects I managed to improve the thumb rules  of estimation, spending considerable time to collect the relevant metrics.  By being diligent about updating this year after year, organizations can improve estimation accuracy.

How are you improving the estimation baselines in your organization? Do you have detailed estimation procedure which uses updated baselines? Share your thoughts.

Aligning the team in practice

Photo credit:Manojk (via Commons)

For the success of a project/program team alignment is critical.  If the team is newly created, there is a pressing need to make it effective soon. For complex projects,  the team dynamics are even more challenging, as the team is never stable. New team members get added as the workload reaches peak and team members leave as per  change in workload or due to other effects like attrition. Bigger teams require  better processes for communication/ coordination for effectiveness.  In this blog post, I share few theories and  practices that benefit the project/program.

According to B.W. Tuchman's theory   teams evolve through forming, storming,norming, performing and adjourning stages.  This has implication for Project Mangers to apply appropriate  leadership styles as per the team evolution stage. According to Connie Gersick's punctuated equilibrium model the initial behaviors and norms have a lasting impact, till they are shaken by a critical event which moves the team  to  reach another level of performance by modifying their behavior and norms. In this model,  Project Manager has to play a critical role, as he or she has a critical role in  shaping initial interactions.

For an effective team, the team needs to be clear about the objectives, roles, processes and relationships.   Project artifacts/events   help a lot, if the team members take active part in their preparation/review.  Let's review couple of key documents below.


Project Kickoff: Usually projects are kicked off by convening the initial  meting with the project stakeholders.  The scope of the project is discussed and clarified. The expectations from different teams  are discussed with respect to a rough timeline.

Project Plan: This  has several sections related to  various aspects which help team alignment. The project purpose, scope and deliverables are described. The various roles and responsibilities are identified. CTQs, Project Schedule, process for review, metrics, shared expectations  are  documented.The document is base lined after review by all team members.

What can't be usually captured in  project artifacts  is how well the project team understands all of the above and acts in accordance with them. The team's  interpersonal relationships play a key role in actual practice.

I realized this when the team that I led  went for an off-site team building session. We reached the venue by evening  and the activities were planned for the next day morning. The agenda was  communicated to all in advance.   When it was  time to start the activities for the day, the facilitator and I were surprised when only part of the team was present at the scheduled start time and others were joining in for close to ten minutes. The facilitator, being from a military background,  became angry at us and threatened  to cancel the sessions as he felt that the workshop will never be productive with this kind of behavior.  We felt sad.  After a bit of self reflection, the activity was  rescheduled after the facilitator impressed upon everybody about the need for meeting discipline.  The meeting discipline was improved as the team developed the meeting norms during the initial team building session and put them to practice.

The office atmosphere does not give much scope to build interpersonal relationships. It is important to assess the team alignment several times during the course of the  project.  This is usually done  by administering a team alignment survey with the help of HR member of the project. In this the team is asked to reflect and rate their agreement level on few statements about the project and team characteristics on a scale of  Strongly agree, Agree, Disagree and Strongly Disagree. As an example,  a survey statement may check the response on the team's understanding of and agreement  with project purpose and the desired results(vision).  Project manager's view  is compared  with the views of the team members. The findings in general as well as where the team's opinion differs from the PM are shared.  This can serve as a trigger to initiate specific actions to address the gaps.

In one instance the assessment revealed that there is a good understanding on project purpose, scope, goals but poor understanding of strategic road map and review mechanism.  The project manager  took an action to present the road map and review process in the next team meeting and the subsequent discussion helped improve clarity. 

The outbound helped everyone to know more about other team members, their  strengths, perspectives at a personal level through team building  games, which typically try to bring the elements of the project into focus in a short time. These  helped a lot in improving  interpersonal relationships which improved the team performance subsequently.

What has been your experience with team alignment? Are outbound sessions helpful for team building? Please discuss/share your views.

Automated metrics from repositories for better project insight

Metrics are important to understand project health.  Every project manager has to present them for  review meetings. Traditionally spreadsheet software was used extensively for  metrics preparation. Project Manager has to do a lot of work to contact team members for status information and then update the  spreadsheets. The metrics are subjective and are delayed.  Most of these spreadsheets also will not be ideal for knowledge management in organization, as these are not archived and available for future reference.This situation has improved with  increased use of   non spreadsheet  tools in the recent times.

Usually tools used for requirements, coding, code review, testing  and change  management and project management,  have  built-in reports. These are useful for understanding the status and issues in a project in a timely manner. These may require customization to conform to the specifics of process followed by the organization.  If the tools are not integrated,  consolidation of metrics requires additional effort and possibly use of spreadsheets again with their inherent advantages and disadvantages. Software analytics is a good alternative when the tools are not integrated.

Open source communities are leveraging tools like MetricsGrimoire  (See sample figure above from Dashboard of Wikimedia Development Community) to mine repositories associated with  configuration management, bug tracking and mailing list for projects and extract useful metrics and present them visually for analysis and action. These metrics are useful  to identify  top contributors, aging of artifacts, velocity of development as well as provide insight into issues.

What is the level of  non spreadsheet tools usage in your organization? How much time is spent in generating the metrics? Is there an opportunity to deploy additional tools, deploy software analytics tools  and develop automation scripts to extract metrics? These are all valid questions which can lead to improved productivity and project success.

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.

Effective risk Management-Actual Risk impact model

Several tools  are used at the project level to identify, analyze and accept/mitigate risks. The  risks that could impact a program/portfolio are picked from the project list based on potential loss exceeding a certain threshold and few risks that could not be handled at the project level and appropriate corrective actions are identified and implemented.   This kind of approach  is primarily focused on dealing with the project risk and does not  highlight  the potential impacts at the organization  as well as leverage the organization resources for risk management effectively. 2010 Deep water Horizon accident  in Gulf of Mexico is one example of how a project risk can cause huge loss to the enterprise, if not handled effectively.

A model of risk impact  proposed by  Prof. Hans Thamhain(Managing risk in  Complex Projects, Hans Thamhain, Project Management Journal April 2013 page 20-35(may require membership of PMI)) helps us get better insight into the nature of risk management at the enterprise level based on major field study  of 35 major product developments in over 17 high tech organizations.  The model is based on a  key observation that successful  risk management is only achieved when project environment is conducive to effective cross functional communication and collaboration among all stake holders. This model  categorizes risks into four groups. Cat-1 risks  are those that  do not impact project performance yet. Cat-II risks impact project tasks and subsystems. Cat-III impacts project performance, Cat-IV impacts project and enterprise performance. The key idea is that a risk can move from Cat-1 and Cat-IV  during its life, if it is not managed well.  A nice example for this is the Toyota's accidental acceleration problem which led to the recall of several vehicles thus impacting the enterprise.

This model helps in understanding the  role of work process, organization environment and people in managing the risks. Some of the  learnings for effective risk management in complex projects from this research include  a)Unchecked contingencies tend to cascade and penetrate wider project areas  b) Cross functional collaboration is an effective catalyst for collectively dealing with  threat to  project environment  c)Senior Management has a critical role in creating a conducive organizational environment d)People are main sources for uncertainty as well as  resources for reducing risk.