In a previous post on “http://herdingcats.typepad.com/my_weblog/2014/05/how-to-assure-your-project-will-fail.html”
target=”_self”>How to Assure Your Project Will
Fail, the notion that the current project
management processes are obsolete and the phrase of
dealing with complexity on projects  is a popular
one in the software domain. By the way that notion is untested,
unreviewed, and is missing comparable examples of it working
outside the specific references in the orginal paper.

But here’s the simplest approach to deal with project
complexity…

Don’t Let The Project Get Comnplex

Nice platitude, It’s that simple and it’s that hard.

Before the nashing of teeth is heard, here’s a “http://www.slideshare.net/galleman/focus-on-the-nine-is-v9″
target=”_self”>working example of not letting the
project get complex.

So how is this possible? First let’s make some assumptions:

• If it is actually a complex project domain, then
  the value at risk is high.
• If the value at risk  is high, then
  investing in protecting that value is worth the investment.
• This means a project governance environment is likely the
  right thing to do. Skimping on process is probably not the
  right thing. And thinking that we can get this done with a
  minimalist approach is probably naïve at best.
• This also means a model of the project that
  reveals the complexity element. Tools provide this insight and
  are applied regularly on complex projects.
• One final assumption. If the term complexity is used to
  describe the people aspects of the project –
  the providers of the solution and the requester of that
  solution – then that complexity has to be nipped in the bud on
  the first day.
• • You simply can’t allow the complexities of the people
    aspects to undermine the techncial, managerial, and
    financial aspects project.
  • This is an organizational management problem and the
    processes to deal with it are also well defined – and most
    time ignored at the expense of the project’s success.
  • Here’s a case study of how this id
    done  “http://www.slideshare.net/galleman/making-the-impossible-possible-11761602″
    target=”_self”>Making the Impossible
    Possible. It’s hard work, it’s difficult,
    but doable.

Here’s the steps to dealing with project complexity that have
been shown to work in a variety of domains:

• Define the structure of the project in a formal manner.
  “http://en.wikipedia.org/wiki/Systems_Modeling_Language” rel=
  “wikipedia” target=”_blank” title=”Systems Modeling Language”>
  sysML is one language for this. This include the people,
  processes, and tools.
• Define the needed capabilities in units of Measures of
  Effectiveness (MoE):
• • This means defining what business capabilities will be
    produced by the project and assigning  measures of
    effectiveness for each capability.
  • How do we discover these capabilities? Look at your
    business, project, and product strategy document. You have
    one right? No, then go get one.
  • Start with a “http://en.wikipedia.org/wiki/Balanced_scorecard” rel=
    “wikipedia” target=”_blank” title=
    “Balanced scorecard”>Balanced Scorecard for your
    project. Better yet have a Balanced Scorecard for your
    business to reveal what projects will be needed to
    implement that strategy at the project level.
  • Here’s some guidance on how to construct a “http://www.slideshare.net/galleman/notes-on-balanced-scorecard”
    target=”_self”>Balanced Scorecard in the IT
    Enterprise Domain.
  • Once the Strategy is in place, apply Capabilities Based
    Planning. Here’s an approach for using “http://www.slideshare.net/galleman/capabilities-based-planning-v2″
    target=”_self”>Capabilities Based Planning.
• Define the order of delivery of these capabilities, guided
  by the strategy and business “http://www.slideshare.net/galleman/project-maturity-flow-is-the-incremental-delivery-of-business-value”
  target=”_self”>road map.
• • It is straight forward. Define what capabilities are
    needed on what dates for the business to meet its strategic
    needs defined in the Balanced Scorecard.
  • Don’t let the notion of emergent
    requirements happen in the absence of defined
    capabilities. You have the defined needs, the defined –
    monetized – benefits, the Measures of Effectiveness,
    Measures of Performance, and Technical Performance Measures
    for these capabilities.
  • Sure there are uncertainties – Aleatory that are
    protected by margins. Epistemic – protected by risk
    buy down processes or management reserve.
• Manage the development of the solutions through an
  Integrated Master Plan (IMP), Integrated Master Schedule (IMS),
  Systems Engineering Management Plan (SEMP), and the Continuous
  Risk Management process. The IMP provides:
• • The strategy for delivery of the needed capabilities at
    the planned time and for the planned cost to meet the
    business goals.
  • The Measures of Effectiveness (MOE) and Measures of
    Performance (MOP) needed to assess the fulfillment of the
    needed capabilities delivered to the customer.
  • Technical performance is stated in Technical
    Performance Measures (TPM) and Key Performance Parameters
    (KPP) both derived from the MOE and MOP.
  • The SEMP describes the what, who, when
    and why of the project.
  • There should be a similar description from the customer
    stating what purpose  and when
    the capabilities are needed.
  • These two descriptions can be grouped into a
    “http://en.wikipedia.org/wiki/Concept_of_operations” rel=
    “wikipedia” target=”_blank” title=
    “Concept of operations”>Concept of Operations, a
    Statement of Work, a Statement of Objectives, or some
    similar narrative.

Let’s pause here for a process check. If there is no narrative
about what DONE looks like in units of measure
meaningful to the decision makers (MOE, MOP, TPM,
KPP) then the project participants have no way to
recognize  DONE other than when they run out of
money and time.

This is the Yourdon definition of a  “http://www.amazon.com/Death-March-Edition-Edward-Yourdon/dp/013143635X”
target=”_self”>Death March project. Many who use
the term  complexity and complex
projects are actually speaking about death march
projects. We’re back to the fundamental problem
– we let the project become complex because we don’t
pay attention to the processes needed to manage the project to
keep it from becoming complex. Read Yourdon and
the  “http://www.amazon.com/Making-Impossible-Possible-Extraordinary-Performance/dp/1576753905″
target=”_self”>Making the Impossible Possible: Leading
Extraordinary Performance – The Rocky Flats
Story books to see examples of how to keep out of
this condition.

• Next comes the execution of the project to produce the
  desired outcomes that deliver the needed capabilities.
• • Detailed planning may or may not be needed. This is a
    domain dependent decision.
  • But the naïve notion that planning is not needed, is
    just that naïve.
  • Planning is always needed, just depends on the fidelity
    of the plans. Without planning chaos reigns. From the DOD
    5000.02 formality to the Scrum Planning session – planning
    and plans are the strategy for the successful completion of
    the project.
• All execution processes are risk reduction
  processes.
• • Risk Management is how adults manage projects –
    target=”_self”>Tim Lister.
  • If you’re working on a complex project and don’t have a
    credible Risk Management Plan you’re soon
    going to be working on a Death
    March project.
  • So the first step in managing in the presence of
    uncertainty is to enumerate those uncertainties – epistemic
    and aleatory – put them in a Risk Register, apply your
    favorite Risk Management Process, mine is “http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=30856″
    target=”_self”>SEI Continuous Risk Management, and
    deal directly with the chaotic nature of your project to
    get it under control.
  • Here’s a summary diagram of the “http://www.slideshare.net/galleman/risk-management-processes”
    target=”_self”>CRM process.
• Finally comes the measures of progress to plan.
• • The the defined capabilities, some sense of when they
    are needed and how much they will cost – in a probabilistic
    estimating manner – we can now measure progress.
  • Agile likes to use the words we’re delivering
    continuous value to our customers. Good stuff, can’t
    go wrong with that.
  • What exactly are the units of measure of that value?
  • On what day do you plan to deliver those units of
    measure?
  • Are those deliverables connected to capabilities to do
    business? Or are they just requirements that have been met
    at the User Acceptance Test (UAT) level?
  • Here’s an “http://www.slideshare.net/galleman/project-maturity-flow-is-the-incremental-delivery-of-business-value”
    target=”_self”>example from a health insurance
    enterprise system of the planned delivery of needed
    capabilities to meet the business strategy defined by the
    business owners. This is some times called value
    stream mapping, but it is also found in the
    formal  “http://www.slideshare.net/galleman/capabilities-based-planning-v2″
    target=”_self”>Capabilities Based Planning
    paradigm.

The End

When hear the notion that chaos is the basis
of projects in the software world – run away as fast as you
can. That is the formula for failure. When failure examples are
presented in support of the notion that chaos
reigns and there is no actual, verifiable, tangible,
correctable Root Causes listed – run away as fast as you can.
Those proposing that idea have not done their home work.

But the question of dealing with complexity on projects is
still open. The Black Swans, that get misused in the project
domain, since the term refers to the economics and finance
domain through Taleb, may still be there. There are there
because the project management process have choosed to ignore
them, can’t afford to seek them out, or don’t have enough
understanding to realize they are actually there.

So if Black Swans are the source of worry on projects, you’re
not finished with your project management planning,
controlling, and corrective actions duties as a manager.
Using project complexity as the excuse for
project difficulties is easy. Any one can do that.

Taking corrective actions to eliminate all but the Unknowable
uncertainties? Now that’s much harder.