Project Complexity – Often Overlooked

The project isn’t going as you expected. It’s no single obvious thing; project scope is not huge, but there’s that feeling of bits of rough going, just not flowing smoothly.

You might just be dealing with a project of greater complexity than you believed, if there even was an explicit estimate of complexity at project initiation. Seldom is an estimate of complexity included in a project charter, from my observations.

Projects of greater complexity are situations where one needs to bring out tools and techniques that most PM’s seldom utilize in their day to day work, unless mandated by a PMO. The specific tools needed depend upon what factors are causing that complexity.

First, that estimate: t-shirt sizing usually suffices, but in some project ecosystems and portfolios, quantitative metrics are used. They might even be part of the weighting of that project in the portfolio.

Far more likely is that there was no explicit estimate of complexity. Hardly surprising, with complexity barely mentioned in the latest PMBoK, and not at all in most older editions. But there’s a comforting number of articles in recent years on project complexity, contributing factors, models and templates. It’s up to you to read and determine which are most appropriate to your projects.

Just to get thought processes rolling, a few factors adding to complexity:
– Diverse stakeholders
– Conflicts between stakeholders
– Extended duration of the project, especially if multi-year
– Major impact on the enterprise
– Uncertainty in the overall environment, including economic factors
– Regulatory impact
– Social impact (which may imply political domain)
– Uncertain or very leading edge technology

Consider the overall environment and uncertainty: is it the general economic picture, or are there industry specific factors; or geographic specific elements. Evaluate how volatile the priorities are within the enterprise. What about the stability of the project team, over the life of the project.

One place to start if to review risk management. Go over the plan and the risk identification process. How comfortable are you with the completeness of identification? If there is large impact on the enterprise from some of those risks, take extra care in analyzing and managing them; review those regularly.

PM’s working on construction projects live in a sea of complexity: a challenging regulatory environment; social impact for the geographic area; uncertainty due to weather, etc. But mostly they are conscious of this and develop risk management strategies accordingly It is my sibling PM’s working on IT and business process projects or products are often surprised by the complexity of the effort that they are trying to shepherd home.

Projects with significant social or political impact increase complexity. Pay particular attention to stakeholder management and an explicit, carefully crafted communications plan. It may be necessary to include some feedback mechanism in it, to ensure that communications are working, in both directions.

Projects of higher complexity may need more frequent checkpoints or milestones. Consider doing a Lessons Learned at some of those milestones, not just at project closeout, to permit adjustments during the life of the project. Depending upon the causes of complexity, extra attention may be needed for post delivery.

Go back to some past projects, reviewing ones that had some unexpected difficulty, Try estimating their complexity. For the ones of higher complexity (L or XL in t-shirt sizing), try to write down the factors contributing to it.

For your future, estimating project complexity should encourage a mindful use of PM tools.

Advertisements

Pre-Mortem: an Approach to Risk Identification

originally posted to the PMI NYC LinkedIn group, about March 2018

Among several other fascinating ideas in Kahneman’s “Thinking Fast and Slow”, he cites Gary Klein’s idea of a pre-mortem as a means of compensating for possible overconfidence. As a tool, it goes further, enabling additional identification of possible risks and threats to a successful outcome of a proposed endeavor.

The basic concept is that before an organization is committed to a project, the team, or a group of knowledgeable experts projects one year into the future; from that future perspective, presume the project has been a disaster. Now, analyze the reasons for that negative outcome.

the next step is for the team to come up with some risk management approaches to deal with those, with traditional tactics of avoidance, mitigation or contingency.

Gary Klein’s article on this:
https://hbr.org/2007/09/performing-a-project-premortem

Challenges of Managing Projects Involving New Technology

Projects involving use of new technology present some distinct challenges for the project manager.

As part of project initiation, explicitly distinguish between technology that is only new to your enterprise versus that which is truly new technology, perhaps bleeding edge. As an example of truly new technology, consider Hadoop about 2009: high risk, limited knowledge base, unclear path to solution, lots of unknowns. Especially for those cases, one needs to evaluate up front the tolerance for risk and for failure in the organization.

If mainstream culture in the organization is not well suited for such endeavors, a possible approach is to isolate them, moving them to an entity with a more appropriate culture, that of a Lab or Skunkworks.

Be aware of cognitive biases, and impact on decisions, especially of those in the C-suite, such as hindsight bias:”I knew all along that….”. This may surface as the project progresses, particularly as it encounters significant obstacles.

The business value should be clear, both for complete success and for partial success. How does this effort fit within the company’s strategic direction, both overall and in terms of technology. Estimate what degree of expertise will be needed for this to bring value. What is the impact of failure, and if there is still some return of business value from that failure.

Determine what’s in scope, and where possible, explicitly note what is not in scope, while allowing for discoveries along the journey. Agile forms with their iterative approach may have an advantage over more traditional (waterfall) methods. Waterfall tries to capture all requirements up front, so may have difficulty when faced with lack of clear solution and high number of unknowns.

As features to be implemented emerge, acceptance criteria need to be defined, including definitions of partial success, or of minimum viable product (MVP).

In both project layout and architectural design, try for modularity. Consider use of prototypes where feasible; in software, consider approaches as Test Driven Development (TDD). Try to minimize external dependencies. New tech has enough risk built-in, without adding to it from external sources.

Risk management is always key to project success, but more so when new technology is involved. Include the people element in risk, e.g., staff turnover as well as burnout. Note that as subject is new, that the knowledge base will change during the life of the project.

Watch out for regulatory risk and environmental impact, depending upon the nature of the technology involved. E.g., wind farms and migrating birds.

Depending upon the criticality of the project, try using the pre-mortem technique to better identify potential obstacles.

Communications planning needs to include review of that plan when significant obstacles are encountered. Ensure that stakeholders are all identified, and that they receive appropriate levels of communication, Special documents may be needed for stakeholders, to deal with team turnover, and to ensure that what is being discussed is agreed upon Use FAQ’s, glossaries, visual representations. For example, clear and consistent vocabulary used in drone technology, or in cybersecurity work.

Part of the project plan needs to have a means of bringing this effort into the mainstream of the enterprise; not just ongoing support of this product, but of the potential use of the new technology.

There are many more areas to consider, but this should be a good starting point for project management of new technology.

Paired Project Management

You probably have seen some of the statistics on project success rates, or more aptly, the rate of the lack of success. The Standish Group’s Chaos report is often cited as one source. There are numerous causes, but one suspects the statistics are even worse for projects of greater complexity.

There are multiple factors to project complexity: the impact strategically or financially to the enterprise; the overall stability of the environment; degree of uncertainty (in multiple dimensions and constraints – from, “is this definitely the right path?” to “will key resources remain”); the number of different disciplines involved; severity of social or legal impact; etc. Far too often, project managers don’t evaluate complexity at project initiation, only realizing the project is of significantly more complexity when difficulties are encountered.

Rule of thumb in planning:
the more complex an undertaking, the more likely any one individual will miss some key element.

One of the interesting practices in the Extreme Programming (XP) movement has been use of pair programming. Two programmers sharing a keyboard and monitor, working together. The typical dynamic is that of driver and navigator; periodically, they switch. Necessary conditions include compatible temperaments as well as cultural support in the team and organization. There are other factors, well discussed, as the use of this practice is about two decades old. Numerous articles discuss paired programming, its benefits (e.g., knowledge sharing), difficulties, and variations.

One of the results of this has been a significant decrease in defects. This is key towards the suggestion: for projects of greater complexity (starting at the upper range of medium), to better ensure project success, use a pair of project managers.

In addition to the need for compatible temperaments, the working environment needs to be supportive, with management not hostile to the idea.

During the initiation phase, having a 2nd knowledgeable viewpoint helps minimize likelihood of anything being overlooked in creation of a work breakdown structure (WBS); better communication planning; more inclusive and clearer risk identification and management strategies.

During project execution, .having two different people allows for more tailored stakeholder management, more bandwidth for individualized communication. In meetings, one can lead the meeting, with the other having the focus on analyzing the meeting dynamics, better able to avoid conflicts or facilitate their resolution if such arise, or even just taking better notes than one person trying to handle both.

If things start to really go badly, it is advantageous to have two perspectives, two sets of experiences upon which to draw, to turn the situation around.

Evaluate project complexity and success rates in your environment. If those rates are not satisfactory for projects of greater complexity, try paired project management.

Islands of Competence

“Islands of competence” is a term devised by Dr. Robert Brooks, psychologist at the Harvard Medical School, to refer to the distinct strengths that each individual has.  Instead of focusing on fixing deficiencies, it changes to one of identifying and reinforcing strengths.

While his thoughts were about individuals, particularly those with learning disabilities, they apply to growth and development of any individual, and to teams as well.

Identifying strengths is challenging, either for individuals or teams.  As individuals we are acutely aware of our weaknesses, but oblivious to many of our strengths.  Teams may be even less aware of their special powers as a collaborative group.

Observe behavior over time; that should provide a starter list of strengths.  Ask the team, possibly in the context of a session on Lessons Learned, or an Agile Retrospective, especially after a product release.

The concentration on improving areas already perceived as strong should build self-esteem and team morale.  From that momentum, and feeling of confidence, it is then easier to cope with improving deficiencies.  That positive feeling improves the ability to face challenges and difficult circumstances, increasing resilience of both individuals and teams.

Reference

Dr. Robert Brooks http://www.drrobertbrooks.com/monthly_articles/0506

 

Innovation and Cognitive Diversity

 When we form a team, we tend to populate it with people whose thought processes are similar to our own. It’s natural, in part because it’s easier on us. People whose priorities and thought processes are distinctly different from our own are potential sources of friction within the group.

 But when there’s a need to address complex issues, come up with innovation, combine components in new and value-enhancing ways, then having a team that is cognitively diverse is of benefit. Cognitive diversity means diversity in how we think, in how we perceive and prioritize those perceptions.

 There are some necessary conditions for cognitive diversity to have benefit: team members have to be able to get along with each other, and to work together towards a goal commonly agreed upon.

 Cognitive diversity implies that some members of the group will perceive the world differently, and have distinct mental toolsets associating those perceptions. The interaction between cohesive yet distinct viewpoints allows for fresh solutions, perhaps combining existing processes or elements in new ways.

 

Improving Requirements (Strengthening Waterfall)

One of the weaker phases in waterfall product development is the area of requirements.  Unclear or incorrect requirements are recognized as a major cause of grief on projects, if not outright disaster.

What is your feeling about the relationship between the requirements document and the ultimate product delivered?
How readily does the requirements document map to the required functionality?
Does it include a description or list of functionality that is out of scope? (“Thou shalt not…”)

In general, part of the problem is that there’s no real QA process on the requirements document, typically, only a user sign-off.  That’s an approval, not a QA process.  If the document is much over 10 pages, this is about as useful as handing someone a globe to use for direction to someone’s house for a holiday dinner.  You’re lucky if you even wind up in the right town, let alone the right neighborhood.

Typical waterfall environments have a QA function, usually for testing the finished product  Too often they only get involved late in development, often after all coding is allegedly done.  Why restrict their role so much?

Get them involved sooner, and involved with the analysts creating that requirements document. Involved, meaning interacting and talking directly to each other.  QA is designing the tests and should be able to identify unclear areas of the requirements, perhaps even missing parts. To flesh it out further, the QA group designs the tests based upon the requirements, and the business (not the BA who did the requirements) then reviews the test structures for completeness and accuracy, closing the feedback loop on the requirements document.  That process is independent of coding; it can start before any coding.

Another wobbly area is the clarity of the requirements for the developers.  Of course, clarity is only important when the document is actually read.

Another way to have some QA process for requirements is to have something similar to a peer review for coding, but in this case, instead of code, it is the requirements that are reviewed.

Come up with your variation of a QA process for requirements, one appropriate to the culture of your organization and resources available.