PM101 U4: Implementing and Managing a Project

xxx






XXX

INTRODUCTION: Even after resources have been promised or even [partially . . . ?] delivered, strategic change projects remain challenging. Not just the grand projects, the small, almost informal ones too, as such are likely to be put on the table in light of high uncertainty and high degrees of disagreement on the way forward -- hence the reminder illustration.

The pivotal issue for Implementing and Monitoring a project (the focus for this fourth unit in our workshop) thus has to be on sustaining critical mass and making controlled but flexible adaptations in the face of obstacles, natural challenges and uncertainties, as well as active skepticism and even opposition.

Resemblance to military combat in challenging terrain is not a coincidence: a battle is a project, or more accurately, two projects in contest. That is why we must bear in mind that -- as the German General Moltke the Elder was fond of saying -- "no plan survives first contact with the enemy."

(Plans and their parent organisations, in short, are best understood as carefully developed credible frameworks that give insight and provide resources to move to the goal in a reasonably controlled way in the face of unpredictable challenges. Plans are no substitute for capable, insightful and flexible, sound leadership at all levels. Nor does the impossibility of precisely planning the future in a rigid way excuse the opposite fallacy: refusal to plan on the presumption of genius at improvisation, or overconfidence that one holds the high cards and the high ground.)

 So, in this unit, we begin looking at implementation and management with:

The John Boyd OODA Strategic-Operational-Tactical
Decision-Action Framework

John Boyd was a Korean War era Fighter Pilot and strategic thinker whose thought, advocacy and theories revolutionised aerial combat, the acquisition of combat aircraft [e.g. the F16] and military strategy. One of his key contributions is the OODA -- observe, orient, decide, act -- loop, which focuses the challenges of high risk, high potential loss, high uncertainty decision-making:

Instantly, we see just how challenging leadership of a project in a chaotic or even just a relatively uncertain environment is. For, all four main processes must go on simultaneously in interaction, with the fourteen sub-processes structuring that interaction. Where each implies even more background context and dynamics, in a context where delay may be fatal, and rashness is also exceedingly dangerous.

Further, we again see the relevance of the ALARP approach backed up by solid contingency planning as part of a good log frame based project plan:

The direct implication is, that we need good, capable, bold (as opposed to either indecisive or rash), soundly informed, flexible, committed, teamwork-capable, trusted and trustworthy people in key positions for managing each level of the strategic change portfolio of projects and programmes. That already implies the need for idea originators, champions and sponsors backed by Godfathers. Yes, key staffing decisions are pivotal strategy decisions. (And if just one key person walks away in disgust, a whole portfolio can blow up; vicious in-fighting must not be tolerated.)

 It also points to the need for incubator facilities -- right up to the level of  the justly famous Lockheed Skunk Works -- as in, where the Kickapoo Joy Juice gets brewed -- if need be:




 (Kindly, pause and view this lecture on the history of the original Skunk Works.)

It is well worth the further pause to ponder Kelly Johnson's fourteen rules and practices for:

THE SKUNK WORKS PROGRAM RULES & PRACTICES

1. The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.

2. Strong but small project offices must be provided both by the military and industry.

3. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).

4. A very simple drawing and drawing release system with great flexibility for making changes must be provided.

5. There must be a minimum number of reports required, but important work must be recorded thoroughly.

6. There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program.

7. The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.

8. The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.

9. The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.

10. The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.

11. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.

12. There must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.

13. Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.

14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.[HT: Lockheed-Martin, host for the Skunk Works since 1943]

The key elements of successful innovation are clearly embedded in these rules for perhaps the most famous of all long term innovation incubators.

We will need as well to carefully mark the difference between responsible critics and ruthless idea-implementer hit-men and their destructive rhetorical torpedoes (or, knives ready to be slipped in between the ribs -- BTW the critical danger distance for a knife-man is about 20 feet . . . it's not just at arm's length).

All of this highlights the pivotal importance of the implementer-oriented log frame. for, this is a one-page, at-a-glance overview of a project's logic, critical success factors & their key indicators, assumptions & risks, ever changing circumstances and challenges that call for prompt contingency responses. Where of course, if it cannot fit into a landscape mode 8 1/2 x 11" letter-size sheet, use 11 x 17" tabloid-size . . . it is that vital to be able to see the overview at a glance:

In short, the implementer-oriented log frame is a key "dashboard" that indicates the dynamics of a proposed or active project. It serves as a main  tool to structure and summarise observations and the orienting analysis behind a plan to guide decision and action.

I add, a UN-derived explanation of the logic, as extended into "Results Based Management" (which seems to be one of the latest wrinkles on log frames and project cycle management thinking):

Hardly less useful is a similarly structured Gantt timeline chart, especially one that illustrates the work breakdown structure in its activity list and highlights the "now" state of planned vs actual progress (whether at project or programme level), e.g.:

Notice, here, the use of a now vs achieved "string" joined to "indicator lamp" Red- Amber- Green measures of degree of achievement of deliverables at milestones. This then helps to guide progress/ gaps analysis and triggering of contingencies.

(As a refinement, evaluation point -- milestone -- stars can also be colour coded. And yes, it is implied that rework and contingencies can address inadequate milestone performance so that we can show how well or poorly all major deliverables to date have been achieved. Onward, the MoSCoW type priority rules can be used to adjust what we try to do onward. This includes premature termination and accepting what has been delivered to date as the final result of the project; escalating commitment to a demonstrable failure will only increase the loss, as a rule. That's why milestones have another, more chilling, name: kill points. [NB: In some happier cases, a project may perform better than expected, delivering relevant results quickly, and can be closed earlier than expected. Some projects can even be extended as new opportunities open up.])

And yes, all of this and more is involved in the Boyd OODA loop; the management of a project is dominated by responding to contingencies day by day, leading to progress by "tacking upwind" through good teamwork and situationally aware leadership.

It is helpful -- HT, VicHealth -- to draw out the comparison briefly (and indeed . . .  a sailing crew in a race is carrying out a project):

A sail-boat cannot sail directly into the wind, there is a "no-sail zone" where the wind will directly oppose sailing and will not generate adequate lifting forces -- yes, a sail is in effect a wing. So, to make progress against a wind, the boat has to be sailed in a zig-zag pattern that requires careful teamwork. Indeed, at a certain point in the tack, the sail may "luff," acting like a drag device (it then wobbles and flutters like a flag in a strong breeze). So, also, we can see three phases:  [a] ready, [b] the turn and [c] the acceleration on the new tack. The skipper is responsible to spot good zones to tack, avoiding local pockets of relatively dead air. The crew has to be alert to the need to tack, and must have the drill down pat as the turn necessarily loses speed; if it is not smoothly, correctly and swiftly executed, the boat loses speed and time.

This instructive example thus illustrates several things concerning project implementation management and teamwork:

First, a video (as seeing live action is much more instructive than simply talking or a still picture):


Now, some notes that draw out principles of project teamwork and day to day leadership, based on this instructive example:

Tacking

• A project needs one or more capable teams, with situationally aware credible leadership -- the OODA challenge.
• A project team needs to understand that moving towards goals often faces a challenge to move into a headwind.
• Sailing upwind will slow down a boat relative to the best points of sail -- which are more or less across the wind ("reach") for a modern type sailing boat. This is due to the lift-based action of triangle-type sails. However, tacking is often necessary to make progress towards a goal.
• This also involves sailing in a zig-zag pattern, towards interim objectives that are not the same as the overall goal but help the team make progress towards that goal.
• A very good question for a project team to ask is: what are the "headwind" challenges and forces that -- while apparently opposed to our objectives -- can be used to energise well-judged progress, if we harness them correctly? 
• Likewise: how can we best work as a team to tack upwind in our situation?
• The team needs to recognise that there are appropriate tools, techniques, tactics and processes that must be carried out at the right time in the right way to make good progress while tacking.
• Capability, alertness and credibility of leadership, preparation and effectiveness of the team (which should be drilled together beforehand to be ready for the "race"), co-operation and unity of smooth action are essential to tacking right.
• Tacking involves definite steps in the right sequence and each member of the crew plays a significant role, while avoiding blocking others in their own work or getting tangled up in the works. 
• So, what are the drills that must be practiced and what are the preparations must be made ahead of time, by whom, when, how?  (Thinking ahead of the current step.)
• Crew members should be alert for emergencies and should be ready to respond to such contingencies on a moment's notice. (E.g., what happens if someone falls overboard or something breaks or goes wrong? [Often, there is no time for confusion, so likely or potentially harmful contingencies must be foreseen and prepared for.]) 
• If a tacking duel is in progress between competing boats . . . cf. here, high skill is needed and fair contest in accordance with the rules becomes an issue. (Where, there are umpires who can and do impose penalty turns.)
• Once the tack is executed, the crew needs to be alert to the next action that may be called for, e.g. the next tack.

In short, just by pondering an instructive example, we can learn many insights on how to move ahead with projects in general. (It may be a useful preparatory drill for a new project team to study this example and use it to compare to the project in hand. [This is a case of learning and capacity-building by inductive example.])

This allows us to bridge to looking at:

Project team-work, work breakdowns/packages and timelines

Projects typically require teamwork, to tackle an array of tasks that are linked by the process logic of the project. These must be tackled across time, and cumulatively lead to achieving the project's objectives. That's why log frames, work breakdown structures and timeline charts are so important and helpful in planning, carrying out and managing a project, e.g.:

Work naturally breaks down in a pyramid pattern, all the way down to work packages for individuals and groups, as we can see from our house-building example:

 Preliminary forms of these planning charts should be a part of the project concept note and the more formal proposal/ business/ strategic change case; not least, because of their at-a-glance, one page format. When a project is approved and resourced, the project charter that states approval, organises and launches the project, also granting powers to key officers, should include the proposal, charts and other key documentation as technical appendices. Then, a standard reporting schedule should require a developed version as part of the inception report. Interim variations should be tracked, and these main charts as updated should be part of the regular milestone "progress/ gaps/ follow-up"interim  reports. As a part of the evaluation and project closing, they should be specifically discussed.

For simple projects, a phased, planned vs actual income and spend budget tracking sheet is also helpful at milestones. Perhaps:

A key insight for all such efforts is that activities require input resources, which are limited and should not face surges beyond availability per unit of project timeline. Accordingly, there is often a trade-off between time and resource use (including costs), and of course this also trades off against time and contingencies that go sour. We are back at the iron triangle three-way trade-off: scope of deliverables, costs, time; constrained further by the necessity of adequate quality.

Such quality- of- a- project (and/or of its deliverable results) typically involves various factors:

• fitness for purpose: assured adequate scope, balance and level of features, ease of use & ergonomics, durability, aesthetics and capabilities or benefits
• reliability [= it will consistently be there to do the job when needed], tied to ease of maintenance support
• credibility of product and provider (often, brand strength -- think: Mercedes Benz vs. anybody else for vehicles)
• state of the art for a given technology
• credible progress of the state of the art (including, through the project!)
• effectiveness and efficiency: doing the right things and doing them without excess waste of resources
• economy -- giving "good value for money" relative to alternatives
• affordability . . . arranging how to own or lease it to good market advantage
• ready accessibility: products (goods, services, ideas, etc) are available conveniently when and where desired without undue delay or difficulty of finding it
• safety and manageable risks in development, production/operations and use
• duties of care and legal risks (how will you defend X in court?)
• being ethically responsible (informed by sound principles/ values)
• timeliness in delivery or getting to commissioning
• etc.

Such quality is so important that in aggregate it defines performance; and, quality assurance is thus a key aspect of project management. Defining a balanced, duly weighted adequate quality of performance across these factors is also a key part of project planning and of consultation with stakeholders (especially sponsors and users or beneficiaries and/or those who suffer adverse impacts . . . "dis-benefits").

This then leads to the significance of the trading off of performance against timelines -- and deadlines -- as contingencies arise. Where, the Pareto principle often applies; in a simple form, the 80/20 rule . . . 80% of effect comes from a key 20% of input, so there may be a performance-time cushion if that last 20% of effect can reasonably be given lower priorities. That's why implementers, sponsors and users have to negotiate and continually re-negotiate under the MoSCoW rules for a given project:

MUST have this requirement to meet the business needs.

SHOULD have this requirement if at all possible, 

(but the project success does not rely on this).

COULD have this requirement 

(if it does not affect the fitness of business needs of the project).

WON'T represents a requirement that stakeholders have postponed 

(due to the timeliness requirement)

As implementers tack upwind and face contingencies, as a rule some things that would be nice to have are going to have to be trimmed.  This already points to the issue that for any reasonably complicated project, there is a major administrative headache to track, document and communicate adjustments. Jennifer Whitt of Project Management Videos presents the paper vs computer trade-off here:




Thankfully, we are discussing "simple" projects, for which a DAILY diary/journal of actions, notes and changes may be enough. And don't overlook using a tablet or smart phone to snapshot a sheet on a desk or a wall-sized chart or whiteboard or even do a short video summary presentation; as Ms Whitt demonstrates. Self-documentation helps. Multimedia projectors . . . and now big screen TV's . . .  used as monitors and teleconference screens also help with communication. Bigger projects need dedicated staff for administration and communication. Specialised project management software is important also. In addition to the well known products, for simple projects or personal use consider things like ProjectLibre, an open source package.

A very good example of the sort of log or journal in view is provided by Admiral Grace Hopper, when she identified the famous case of the actual bug -- duly taped to the paper -- in one of the first digital computers, then under development:

All of this is practically quite useful.

But, the really tricky issues arise when critical success factor assumptions break and must-haves begin to give trouble. Painful choices may have to be made at that point; up to possibly the premature closing of the project.

This brings up:

Dealing with troubled, dragging or blocked projects

Projects can and do fail or go astray or slow down or even stop at any phase of the life cycle. The log frame view of this is, such generally reflects a breakdown or absence of critical success factors, particularly critical mass of support. Often, this manifests in a shift to fears that technology will not come through and/or renewed controversy about required performance/quality.

In short, if a project stalls or stumbles or begins to wander into chaos, look for unmet critical success factors, especially at bottleneck points where the process flow hits a key node that constrains the overall process.

Where, it is a longstanding view that there is usually a critical, low slack path in a project that drives its overall duration. If this path is being delayed, it should be "crashed" by injecting additional or rushed -- and typically more costly -- resources to bring it back on schedule. Unfortunately, sometimes this is counter-productive as new people have to be brought up to speed, distracting the present team and actually reducing directly productive effort. This tends to happen where the product is non-routine and crashing may actually make the delays worse.

A more recent approach based on Goldratt's Theory of Constraints looks at this sort of path in terms of it being tied to not just time but availability of key resources. A useful video overview is:



This approach builds on the classical critical path view; which uses activity durations that will normally be estimated and negotiated on "being safe." Psychologically, if an activity finishes early, remaining slack will be used up to "gold plate" the deliverables; much more likely distractions, other deadlines, juggling multiple tasks and last minute urgent rushes will lead to eating up the buffer and looking for more time.  The predictable result is delayed projects.

So, the critical chain approach revises this to get more realistic scheduling. First, by exerting an informed judgement as to the implicit buffers then squeezing durations [often to 50 - 80% of estimated time -- the "most likely/reasonable" time], then a chain buffer (= project buffer) is created. The work package leader for each successive task in the chain is then given a top priority token (= "baton") to enable a speed-up if required. The percent of chain-task completed vs percent of remaining chain buffer then allows managing the critical chain. MosSCoW priority rules or the like will allow for balancing adequacy of quality, scope/level of features and keeping to time. Also, feeder chains require end-of-chain buffers . . . lest they become the new critical path; and, key resources will require "early arrival" buffers . . . lest they block the start-times for critical chain activities, eating up the project buffer. (And yes, I know that timeline charts with such elaborations may well require significant capability-building effort if implementers, managers and decision-makers are to use them appropriately. A buffer driven by the uncertainties of real-world work is not a reflection of laziness, incompetence or waste. If this becomes a problem, it may be advisable to revert to PERT/CPM style precedence network charts with three point duration estimates. Hopefully all of this will not be needed for "simple" projects. But then proverbially, "nothing is as simple as it at first seems to be.")

As MS Project is a common PM Application, the Office advice page on using it with Critical Chain approaches, here, may be of some help. Illustration (with some remarks on Beta Distributions and PERT approximations):

The timeline for the critical chain may typically be estimated from:

sum of "median" activity durations

+  1/2* x sum of activity buffers

(*i.e. it assumes some go over, some under)

+ 1/2* x sum of key resource buffers.

That resulting timeline is then the estimated project duration.

As the project proceeds, management can then focus on percent completion of tasks vs. percent of buffer remaining. 

(NB -- if you are interested: Cf. UMT lecture here. [Review paper is here. Six Sigma discusses the beta distribution and three-point estimation here: early, likely and late finish.  The underlying beta statistical distribution -- capable of modelling "bells", U's, J's and reverse J's -- is helpfully discussed in this thesis.]  I suggest that a "lite" step for managing simple projects would be to put a bloc in Gantt timeline charts for explicitly scheduling availability of key resources and for showing how that availability issue constrains activities/timelines. Buffers are of course contingency plans, and if that is needed can be pointed out in the relevant log frames.)

How do we know that critical constraints exist? Apart from common observations, we can apply an insight from physics: F = m*a so a = F/m. If mass did not constrain the effect of force [ m --> 0], everything would accelerate instantly to any arbitrary speed. That does not happen, so the issue is to find the key constraint and to work with it to get better effectiveness and efficiency, economically and ethically. For instance, in a sailing race upwind leg, the dead zone in which the wind will not provide motive power is a key constraint and the art of tacking is the key strategy to work with it.

This latter approach has often had impressive impact on performance, and is reflected in the strong trend of moving IT projects to Agile methods. The idea of bringing together a "scrum" of people to concentrate effort during a definite timebox to keep up delivery and quality assurance of adequate performance then passing to the next cycle in succession clearly reflects critical chain thinking.

A 2011 lecture by the late Dr. Eliyahu Goldratt, gives food for thought:



All of this refocusses the 3-4-5 governance factors for the host programme and the project:

As we look at the outer box, we can see that as a project moves through its life cycle:

. . . we are able to update our understanding of trends and shocks, leading to a clearer SWOT-picture. This then raises the question as to whether the current project track is robust and sufficiently advantageous over business as usual to justify continued effort, expense and investment.

Or, in more positive and specific terms, we may ponder:

•  how can the project become better value for money and a better risk management prospect? 
• What are the pros and cons of the project alternative vs those of business as usual?
• How does the project fit in/ conflict with/ transform vision, mission, values, goals and strategies?
• Should we go there, why or why not?
• What is happening with critical success factors, underlying assumptions and contingencies?
• What is happening with the iron triangle factors?
• Is the overall delivered result likely to be fit for purpose and provide good value for money, affordably -- why or why not?
• Is there a credible way to tackle bottlenecks?
• Is this project still supported by an adequate critical mass coalition: idea sources and champions [with viable implementing teams . . . ], sponsors [often, Project Sponsors], Godfathers [often, "Owners"]?
• What is the trend of that support?
• Why?
• Can the trend be made more favourable?
• What is happening with communication?
• Where are the responsible critics? The hit-men?
• Do we have project marshals capable of handling the hit-men? 
• Do they have adequate "ammunition" and "artillery"?
• Is there enough organisation or community political capital to keep going?
• What are the risks of abandonment or refusal to pick up and run with this project?

In the case of aid agencies and programmes, it is perhaps necessary to take a means-ends look at portfolio of initiatives vs. reasonable goals:

Beyond a certain point, if there are but few initiatives or there are but few that have or could have significant impact on long term development goals, something is in need of fairly drastic reform. For, this means there is a major capacity bottleneck that is blocked or severely constricted. Nor, is it good enough to point to lack of capacity on the part of the aided community: such lack of capacity is why aid is needed in the first place.

The issue is how to address that bottleneck.

Fixing the Capacity Bottleneck

Capacity (or rather, its lack) seems to be a key constraint.

Capacity can be understood as ability to take sound decisions in good time and carry forward their implementation without undue delay or risks. It exists in individuals, in organisations and in communities.

 Individuals need skills, knowledge, character, initiative and networks of support. Organisations need to foster positive synergy so that the overall effect is greater than the sum of the individual parts because strengths complement and multiply one another harmoniously; creating centres of excellence. Communities in turn can harness another level of social capital, as clusters of centres of excellence and those emerging or established as community level leaders create a critical mass for growth, prosperity, development and general welfare as well as ever improving quality of life. In particular, as ability make good decisions and to make them stick through to effective implementation is a key underlying concern, quality of governance is also deeply involved.

This points to the FAO summary of community-level governance and environment dynamics . . . including the implied role of the media as a vital feedback system that may well shape the community's agenda:

When key elements of required capacity lacking or are not fit for reasonable purpose (or are acting abusively or incompetently or in accord with unsound agendas . . . ), it constrains progress and may trigger down-spirals into stagnation, chaos and despair.

There needs to be a steady stream of capable individuals, which points to the critical role of education and linked health and social welfare systems. Also, there is need for sound career paths and professional development in organisations and the community at large.

Organisations must avoid the situation where envy, selfish ambition, polarisation and greed promote a silo mentality of piling up power and resources in rival mini-kingdoms that are at best in a cold war of mutual mistrust. Similarly, accounting systems and financial controls must curb corruption and waste.

The community needs to move to harmony and a common achievable vision.

In the Caribbean region of post-slavery, more or less post colonial societies riddled with a history of institutionalised racism and the legacy of the cynical policy: divide and rule,  that is hard to achieve. One step is that centres of excellence can host strategic programmes of transformation, providing they have good and stable leadership. Once such are in place, capacity can be built as part of the process of building a sustained effort. Establishment of proper programme based project cycle management then enables undertaking of projects that have good prospects.

Then, gradually, a portfolio of initiatives to effect strategic change and ultimate transformation can be undertaken.

And so, cumulatively -- sometimes imperceptibly -- transformation can be fostered.

So, we must again face the challenge of change:

 FOR DISCUSSION: Abcdiary

xxxxxxxxxxxxxxx