Complicated or Complex? Classifying Projects

Complicated or Complex

How would you define them?

Several years ago I would have thought they were nearly the same thing.

Apparently, they are slightly different.  

In a recent study on the relationship between IT Project Complexity, Complication and Success, David J Williamson drew a distinction between complication and complexity by defining complication as related to:

  • Factors of scale, including extensive and detailed requirements
  • Large and geographically dispersed project teams
  • High project cost, and
  • Long project durations

In contrast, complexity emerges when

  • Project objectives are not clearly defined
  • Requirements are unclear and volatile
  • The project incorporates significant technological or organizational change, or
  • The project environment has extensive political and social influences, dependencies and constraints

Sounds like fun, huh?

Several years ago I would have thought that the dispersed project teams and the scale of a project would have qualified it as complex.  At a minimum those characteristics would have made communications and tracking progress difficult and complicated the execution of the project.  Teams working on opposite end of the clock have to work harder to share information and share a common purpose. But problems like these can be solved with standard PMBOK tools & techniques.

A project with constantly changing requirements or bleeding edge technology is complex by its nature: it’s harder to find a process that fits the way the team works and harder still to manage.  The distinction may not seem significant when you feel like pulling your hair out because of an issue, but it’s justified.  As the study found, complex projects “can behave in unpredictable and uncontrollable ways.”  Because of a project’s complexity, you may be ‘changing your process as you go’ to get the work done.

In the end, I was convinced of the difference.
What do you think?  Leave a comment or send me a tweet, my id is jgodfrey.

Dealing with Uncertainty

Quote

Project management used to be about driving out uncertainty.  You nailed down all the deliverables at the outset and fine-tuned your specs so implementation could be as routine as possible.  Sure, there were always a few surprises, but overall you had a pretty good idea of what to expect.  In many of today’s complex projects, however – whether they involve new-product development, IT installation, or internal process improvement – uncertainty simply can’t be eliminated….

Studies of exceptional project managers in fast time-to-market industries show that the initial phase of a complex project, often referred to as the ‘fuzzy front end’, has a disproportionally large impact on end results.  So it’s important to tread carefully.  Resist the urge to dive right into implementation.  “Defining the problem first gives you greater degrees of freedom in solving it,” says Bob Gill, president of the Product Development and Management Association, a New Jersey-based nonprofit.  “Instead of assuming that your riveting equipment is operating too slowly, if you step back and say, “The real issue is that my cost of manufacturing the product is too high,” you enable other possible alternatives to solving the problem – for example, redesigning the process so that product requires fewer rivets.”

- HBR Guide to Project Management

 

From the News: Using Resilient Risk Management to Fight the Ebola Epidemic

How do you address risks that are uncertain in impact and outcome?
The PMBOK Risk management process attempts to identify specific mitigation responses to pre-determined scenarios.  Risks with unknown impacts can’t have a pre-determined risk mitigation strategy – or can they?

In a recent article printed on the Harvard Business Review website, NPR wrote about a group of risk management experts who looked back to the Black Death to recommend ways to address uncertain risks with unknown impacts.

The researchers coined the term ‘Resilient Risk Management’ to describe a risk management approach where the team focuses on trying to recover from the Unknown as quickly as possible.  As Igor Linkov, one of the co-authors of the paper wrote, “Can we design our countermeasures in a way that no matter what the threat is we still manage to do our best to recover fast?”  I like the idea, but doesn’t this sound like a wrinkle on Disaster Management?

As defined in Wikipedia: Disaster management (or emergency management) is the effort of communities or businesses to plan for and coordinate all personnel and materials required to either mitigate the effects of, or recover from, natural or man-made disasters, or acts of terrorism.  Disaster Management has a phased lifecycle (prevention, mitigation, preparedness, response and recovery) as well.

On the other hand, reframing the process by changing its name might wake people up from the nightmare that all of the suffering and death caused by this virus is inevitable.  Resilient Risk Management sounds a lot more proactive than Disaster Management.  What do you think?  Leave a comment or send me a tweet.  My id is jgodfrey.

Mental Models

Quote

Do you control your mental models, or, do your mental models control you? If you are not aware that you have a choice of how to look at a situation or problem, if you are not conscious of the decision you have taken to use any particular model to understand that bit of the world, then you are using whatever happens to be your default model for situations of that type. The model is running you. If you are aware that you have a conscious choice, and you can weigh up what the benefits of the different models available are, then chances are that you are running the models, and not the other way around. But to be able to choose, you have to have a choice – if you only have one model of organization then, to all intents and purposes, you have no choice. That is the one you will use whenever you think about an organization.

Models are incredibly insidious, models slide undetected into discussions and then dominate the way managers think about their situation. A UK Secretary of State for Health, when talking about changing the National Health Service, used the metaphor of turning a supertanker, observing that this was a very slow process with a huge amount of inertia built in. It was a model of the change process that was often repeated in government and in business. But if a metaphor or model is inappropriate it will lead managers to make assumptions about what is going on that can have very far-reaching consequences, and metaphors always have assumptions built into them. In this case, built into the comparison with steering a supertanker are several fatally false assumptions: that the NHS is one cohesive entity that can be steered, that the Secretary of State is the one doing the steering, and that there is any sort of steering mechanism. The model encourages managers to think and act in particular ways, which in this case were doomed because most of the assumptions built into the model were not valid.

- Patrick Hoverstadt, The Fractal Organization

Is Good Strategy also Good Project Management?

Picture This:
You’re in the middle of a constantly changing terrain – where your resources, external influences and even the tactical objectives can change overnight.  Your objective: to navigate through a valley to the end.

What does this sound like – a tactical situation on a battlefield?  A market that you need to dominate or one of your multitude of projects that you’re juggling every day?

If your answer is: it depends, you’d be right.  In my attempt to fill up my PDU requirement before April of next year, I started taking a business strategy course through The Great Courses: Strategic Thinking Skills.  The more I heard, the more I thought I was hearing PMBOK best practices.

How many times have you heard warnings about:

  • Sunny day scenarios
  • Communication Breakdowns
  • Inflection Points

And yet each of these are examples of failed strategy.

From Sunny Day Strategies…
Listening to historical examples of bad planning drove home the importance of following Best Practices. At the Battle of Bulge, the Germans suffered defeat because of a plan that needed everything to fall into place.  Sunny day strategies fail every time.  Honestly, I’m not sure I’ve ever had a plan fall exactly the way it was originally drawn up.  Something always changes and we need to adjust our strategy in order to finish on time.

To expect a complex plan to align with the stars and our expectations would be a feat of even greater wishful thinking.  Instead of drafting a plan that relies on the best case scenario – we would do our teams and our plans better service by planning in risk mitigation and ensuring that we have what we need to hand over deliverables at the final milestone.

Communication Breakdowns…
In battles, a communication breakdown could lead to a disastrous results.  Just read the poem, The Charge of the Light Brigade to see how disastrous.  Due to a vague order, the calvalry charge was made up the wrong hill.  Replace the wrong hill with the wrong location, release package, configuration item name and you could have a disaster on a lesser scale, but the cause would be the same.  Dropped calls, broken features or rework make no one happy.  Take time to ensure that both sides of an exchange of information understand what was shared.  It’s worth the extra moment to ensure the team has what it needs to deliver.

And Change…
If the business environment changes or the requirements change it can have significant impact on the eventual success of the project.  In battle or business a rule change can result in a change in strategy that could lead to defeat.  When we lock down a project, we like to imagine that nothing changes while we’re cranking out the deliverable over several months, but nowadays business needs change quickly.  Staying in close communication with stakeholders can help avoid delivering a product or service that fails to provide as large a benefit as expected.

We set our sights on an objective and lock down down a project based on assumptions about the environment, resources and an approach.  It should be no surprise that the language of strategy seems to align with project management principles.  I was excited to see the parallels and look forward to learning more in the second half of the course.

Have you seen any other parallels between Strategic Thinking and project management principles?  Leave a comment or send me a tweet.  My id is jgodfrey.

Always Think Bigger, In Both Time and Space

Quote

Always think bigger doesn’t mean you can solve your problem by imagining you are bigger than you actually are.  However, the stuckness you experience as obstacle and conflict is often the result of not seeing the larger environment around whatever is happening. Missing critical points, and sometimes obvious solutions, can be the result of having too narrow a focus.  The antidote to that is to allow your mind to become bigger.  A bigger mind leads to a bigger view, which gives rise to unusual solutions….

Thinking bigger takes place in the dimensions of both space and time….A narrow view of time can not only ignore history, but also cause you to think you must take action sooner than need be….Thinking bigger in terms of space means literally looking above and beyond the immediate conflict or problem at all the elements of the larger environment – the ground, its conditions, all the people connected to it.  Each element in a situation has its own ever-changing constellation of relationships, each is interconnected with the others, and all have some impact on your situation.

- The Rules of Victory: How to Transform Chaos and Conflict: Strategies from the Art of War, James Gimian and Barry Boyce

 

Staying Motivated: Keeping Your Focus on Daily Quality

Quality.

The term itself seems to lend itself to all the wrong images and connotations.  It seems to give off an ‘eat your broccoli’, ‘floss your teeth’ kind of feeling.

Looked at that way, Quality is boring.  When you think about the non-fun aspects of ensuring a quality product: Inspections, reviewing the results of inspections, identifying methods to improve your defect finding, it can certainly seem a little dry.

  • Inspections
  • Requirements Reviews
  • Tracking Adherence to requirements
  • Identifying Critical Customer Requirements (CCR)
  • Prevention over Inspections or Build in quality
  • Continuous Improvement

Remembering the why and the who helps keep me on point.   It reminds me that it’s ok to make a few people unhappy in the short term.  The why is to ensure a quality product for our customer.  Knowing who helps me understand why they need the service to be reliable.

It reminds me of the story of the 3 bricklayers, now so well known that it is probably a cliche.

“Once there were 3 bricklayers. Each one of them was asked what they were doing.

The first man answered gruffly, ‘I’m laying bricks.’

The second man replied, ‘I’m putting up a wall.’

But the third man said enthusiastically and with pride, ‘I’m building a cathedral.'” –Author Unknown

Keeping the Why and the Who in sight helped the third bricklayer remember why each brick had to be laid to the best of his ability.

Looking at Quality with the end in mind gives you a different perspective when you ask for a re-inspection or the review of a document.

Seeing the end result: a happy customer – makes all the difference.  Leave a comment or send me a tweet, my id is jgodfrey.