Authority v authoritarian

A couple of issues have recently come into my frame:

• Authority that becomes authoritarian
• Institutional sustainment that subsumes mission

Re the first point: authority. We're not talking about moral authority here; we're looking at positional authority and the potential abuses of positional authority. Who in the project domain has such a position? There are two:

• Project manager (or portfolio manager, or program manager or executive, depending on scale)
• Governance board (the policy and control guys, to include the project sponsor)

Every leader and every manager wants authority to back up their responsibilities. The Principle of Subsidiarity says put authority with the lowest competent authority in the pecking order. Everyone I know buys into that idea. But, for purposes of discussion, let's just stick with the PM.

What's expected of authority?

---

• Decisiveness: to include willingness and capability to make a decision, to make it timely, with to have sufficient moral authority that it has stickiness. (I hate it when it comes unstuck!)
• Order and protection: hold off the barbarians at the gate so that lean, effective work can be done
• One stop shopping: in other words, not a committee; and, the buck stops here and does not circulate in an endless do-loop of do-nothings
• Ability and willingness to say yes: (this is different from just making a decision) almost anyone in a bureaucracy can say no. That's what bureaucracy is for... to distribute and diversify the risk. Saying 'no' is the same as executing Plan A: Do nothing; often that is the low-risk thing to do. (See: Congress, US, 2012)
• Overcome the ankle biters: Closely related to 'saying yes', this is a little different: it means overruling all the staffers that say no.
• Keep your head when others don't: This is the pressure thing, and the antidote to panic. (See: Mann-Gulch tragedy)
• Transparency: this may be the meme of the day in the decision and authority business, but it's really code for fair and equitable treatment of all the constituents, though some will lose and some will win. It doesn't mean everybody gets a medal. And, this is different from lack of secrecy: Secret has its operational purpose in some spaces. (See: OSB, dead)

So, what happens when authority gets authoritarian?

• Intolerance for an alternate point of view.. that is, intolerance for decision inputs that are not convenient
• Intolerance for not adhering to doctrine... that is, our way or the highway
• Secrecy without operational purpose... no time to justify to the rif raff
• Panic decision making that leads to sacrifice of the little people
• Decision making without consideration of the sacrifice of the little people (See: Stalin, J) 
• No decision making at all... just stall
• No consultation because the decider is self-certain
• The inner circle is small... group think may be all there is

An interesting bit of trivia is given to us by Daniel Kahneman in his book "Thinking, fast and slow": in an authoritrian regime, people can be persuaded to accept a false message by the simple expedient of frequent repetition. Say it enough, and it's believed. And, you don't even have to repeat the whole message. Through a phenomenon known as "priming", the message is effectively repeated by just touching on the priming message.

What about institutional sustainment?

---

Instutional sustainment is about survival of the enterprise.
Fair enough
What if sustainment requires compromise of mission?
Now, we've got an issue. The legitimacy of the enterprise may hang in the balance.

Questions: Should the enterprise go out of business if it can't sustain the mission, or the other way around: change the mission to fit what's sustainable?

My experience is that in the private sector, it's the latter: change missions. That's ok; that's destructive innovation

In the public sector, perhaps it's not so simple: the mission may be everything. If this or that institution can't make a go of it, change the institution.

Now, the hard part is when authortitarian governance intersects with instutional sustainment. It may morph into sustaining the authority over both mission and institution. At the very least, the authoritarian will seek to sustain the structure that gives sustenance to power.

What's the remedy? Well, the Arab spring is one example. Upset elections are another. In the private sector, it's activist shareholders. In the project business, it's solidarity among team leaders.

Bottom line: it's good until it's bad. Then, it has to be resisted and fixed.

Bookmark this on Delicious

How to fail at agile

Ever thoughtful and helpful, Mike Cohn, a leading thought leader on SCRUM, has assembled in one place his top 20 tips on how to fail at agile. You can get this useful article here.

Mike tells us:

Although there are many ways to sabotage your agile project, for convenience we have grouped them into four categories: management issues, team issues, product owner issues, and process issues. In each instance, we will cite an example of someone who successfully caused agile failure, list the general guidelines for failure that the example is meant to demonstrate, and then list alternative techniques you can try to help you replicate the process. We hope this approach will allow you to fail quickly and avoid potential success.

Wow! I wonder if it is as easy as Mike would have you believe? Failure may actually be easier than success with over 20 ways to do it. Such diversity!

 

Here's a few of the better ones:

• GUIDELINE 3: Equate self-managing with self-leading and provide no direction to the team whatsoever
• GUIDELINE 8: Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on
• GUIDELINE 9: Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily standup.
• GUIDELINE 12: Replace a plan document with a plan “in your head” that only you know.
• GUIDELINE 16: Slavishly follow agile practices without understanding their underlying principles.
• GUIDELINE 20: Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.

An alternative is given here:

 

 

 

Bookmark this on Delicious

Risk exposure

---

And then what?!

Robert Gates

US Defense Secretary

 

It has been reported that Robert Gates routinely asked that question when being briefed on a new opportunity. He likely understands that "risk is the price paid for opportunity". Gates may have been thinking about this:

Decisions in the face of uncertainty deal with these questions (the big Three)

• Are all the facts and estimates in the frame?
• Is the information understood for its function, features, and performance?
• Are the consequences known and understood?

Facts come from history; estimates are about the future (there are no facts about the future, after all)

Consequences is another word for exposure. Is the risk exposure understood? Perhaps it is if you internalize these ideas:

 

1. All risk events are not going to happen, or happen to the degree you estimate, so the total risk exposure on the risk register (sum of all costs,or schedule) is overstating the risk to the project

 

2. If you have benchmark data on the probability of occurrence, you can weight the event values by the benchmark data; however, if there is no benchmark data (what we call calibrated data), then there is no point guessing and then multiplying probability by likelihood.... that's just multiplying two guesses, and what's the point of that?.

 

3. Without benchmark data, you can label each risk qualitatively with a high, medium, low possibility of occurrence. While these are also a guess, the guess has a broader range and is more likely to cover the real possibilities. Thus, you can then look at the risk exposure in each broad category

 

4. Based on experience and intuition (learned responses) you can choose which events to keep an eye on, and which events may be mitigated by some strategy

 

5. You can plan buffers and reserves to absorb the unmanaged (low) risks

6. Risk attitudes--and thus risk estimates--are temporally biased: the future is more optimistic than the present for the same challenge.

Sponsors, with their longer business timeframe, are more optimistic than the project manager; thus, sponsors understate risk. But the corollary is that PMs tend to overstate the risk. Thus, there is a constant tension. Project managers are the ultimate manager of this tension!

Bookmark this on Delicious

Leonardo and DONE

I've been reading a really fascinating book about Leonardo da Vinci: "Da Vinci's Ghost: genius, obsession, and how Leonardo created the world in his own image"

In Chapter 4, we learn this:
"Leonardo had trouble with deadlines". Over a three year period from 1478 to 1481, while living in Milan as a painter-artist, he received several commissions for significant works.... and did not get to DONE on any of them!

It appears he kept the down payment, but failed to collect the check that goes with DONE.

In fact, when it came to selecting the 1481 team to decorate the (new) Sistine Chapel, he got left off, allegedly because of his reputation for not getting DONE...to his consternation.

So, why wasn't Leonardo disposed to good project management?  One of his supporters, who was also his critic, said this:

Alas! This man will do nothing at all, since he is thinking of the end before he has made a beginning. ... In his imagination, he frequently formed enterprises so difficult and so subtle that they could not be realized and worthily executed by human hands. His conceptions were varied to infinity

In other words, when came to the WBS, Da Vinci got trapped in the paralysis of analysis. He often began an engagement with a round of experimentation and investigation, sort of a 15th century version of Boehm's Spiral Method.

But we also see a measure of emergence and progressive elaboration in his inability to control scope or contain his imagination

In fact, containing (or constraining) imagination is the challenge in all "thought projects" (Thought projects: those which have intangible requirements, or requirements about intangibles) that have scope with no tangible boundaries and are simply what you can imagine.

I guess the good news is that Leonardo was able to get his game together and left the world with an incredible legacy. I think that's good news for all of us, even the agilists among us!

Bookmark this on Delicious

Writing, and then re-writing

Dilbert: "Your second paragraph is pointless and confusing. Let's just delete it."
Writer: "I'm a highly trained technical writer. What makes you think you can do my job better?"
Dilbert: "That might be a trick question. But I'm pretty sure the answer is in paragraph two"

---

Good writing is not written.... it's re-written. And it's likely rewritten again. Even when you start with an outline and a story board as I do.

I'm working on my fourth book (due to be published early next year) "Maximizing Project Value"; I'm supposed to know how to do this. But after almost a year, I'm still rewriting. Of course, I had a good beta reading team; they really gave me some good stuff.

(By the way, it's going to be a paper book. But if you've got an itch to self-publish an ebook, take a look at this blog on how to write an ebook)

Now comes the editing by a professional editor. And you get this stuff, among other good suggestions:

More about the lowly comma from Ben Yagoda who is a professor of English:

If I’ve seen it once, I’ve seen it a thousand times. I’m referring to a student’s writing a sentence like:
I went to see the movie, “Midnight in Paris” with my friend, Jessie.

Comma after “movie,” comma after “friend” and, sometimes, comma after “Paris” as well. None are correct — unless “Midnight in Paris” is the only movie in the world and Jessie is the writer’s only friend. Otherwise, the punctuation should be:

I went to see the movie “Midnight in Paris” with my friend Jessie.
If that seems wrong or weird or anything short of clearly right, bear with me a minute and take a look at another correct sentence:
I went to see Woody Allen’s latest movie, “Midnight in Paris,” with my oldest friend, Jessie.

You need a comma after “movie” because this and only this is Mr. Allen’s newest movie in theaters, and before “Jessie” because she and only she is the writer’s oldest friend.

The syntactical situation I’m talking about is identifier-name. The basic idea is that if the name (in the above example, “Jessie”) is the only thing in the world described by the identifier (“my oldest friend”), use a comma before the name (and after it as well, unless you’ve come to the end of the sentence). If not, don’t use any commas.

OMG, enough about the comma!

Bookmark this on Delicious

Space X

---

When it's really important to do, the odds are not important

Elon Musk

Founder, Space X



Bookmark this on Delicious

The new Three R's

Are these the new three R's: Responsibility, restraint, respect? (You probably remember the orginial three: reading, 'righting, and 'rithmetic)

We could do a lot worse, and perhaps not better than to adopt the "new three".

• Reponsibility: accept commitment, be committed, accept if you are wrong, and celebrate if you are right.
• Restraint: If you're working with Other People's Money (and when aren't you?) limit yourself to the risks you would take if it were your money; and if your benefactor is more risk seeking, then draw restraint from him/her
• Respect: Sometimes it's hard to respect the village idiot, especially when the idiot is in your chain of command. Nonetheless, if you can't really respect, then at least be civil. No need to be nasty; just get the job done and press on.

If you value relationships (and not everyone does), then perhaps the new three R's are principles you can live by, not only to live with.

(Music fades in here, as I depart)

Bookmark this on Delicious

Small team leadership

A lot of people talk about self-organizing and passing about the leadership baton from time to time so everybody has a chance at it.

It may work on paper--though I'm not sure why the theory would suppose it's a good idea to retire a really good leader so someone else can get some experience; it may even work sometimes in practice, but most of the time in small teams leadership is not settled and effective until "dominance" is settled. 

Say what you will about one for all, and all for one. There's always a dominate figure. Dominance is not synonymous with being a bully. Dominance is a $10 word for pecking order and the ability to project (as in projection) "presence" (as in command presence).

Sharing leadership (in the sense of passing the baton) is often difficult since the pecking order is not easily rotated. Some folks are natural followers, others are managers (task oriented) but not leaders (message and concept, direction, protection, order)

Hersey and Blanchard told us all about this years ago with situational leadership. Most people who know about this (they used to teach it routinely in management school) remember the four S's for the four situations of leaders. But the more important point about the SL model is that is posits a place for followers.

Followers have styles also; some can be very assertive, but nonetheless managerial rather than leader. The idea of SL is that the leader--being the adult--adjusts his/her style to be the compliment of the follower: assertive follower--> delegating leader, etc.

It's true that on some larger scale than a small team, social and institutional emergence is at work. In the event, we can expect self-organization. In the United States, we need only look to the assembly that that put together our Constitution to see how this works. Of course, that self-organization was then ratified by the affected population.

But I'm talking about something on a smaller scale: a dozen people forming themselves first into a working group and then into a committed team. By the time you get to the team thing, dominance will have worked it's will: a leader will have emerged. Managers in the team will have suggested the right organization--that's the self-organizing thing, and good managers can make it work (managers are better at this than leaders, who may have their head in the iCloud or some such). Task leaders and the team leader will then figure out the right styles... and off we go!"

And, in what direction are we going? Should we follow the customer, lead the customer, or ignore the customer in the short run? That last thing, ignore, is not all bad, because as Henry Ford said (paraphrase): if I had asked what they wanted, they would have said "faster horses"

The answer, of course, is "it depends..." (And, it always does).

Bookmark this on Delicious

Risk Management: something new?

When Tony Hayward became CEO of BP, in 2007, he vowed to make safety his top priority. Among the new rules he instituted were the requirements that all employees use lids on coffee cups while walking and refrain from texting while driving

 

The quote is the opening paragraph in an article in the June 2012 edition of the Harvard Business Review by Robert Kaplan (Balanced scorecard co-author) and Anette Mikes entitled: "Managing Risks, a new framework"

I'm not sure there's all that much new here, perhaps nothing new at all, but here's a summary of the framework:

There are three categories of risks:

1. Preventable risks for which there's no business upside per se. Coffee cup lids go in this category
2. Opportunity risks for which there might be substantial business upside: programs and projects for 10,000 foot deep water wells belong here
3. External threats over which there is little or no control, but may require defensive measures: tsunamis fall in this category.

Preventable risks are the work of safety committees, standard policies and procedures for behavior and the like, health and welfare HR folks, and a myriad of workplace specifics like blow-out protectors that actually work.

If you do all this, you may not attract or retain a single customer. If you don't do this, you may spend a lot of money on non-value add adjudicating the misfortune of you and your associates. It may sound counter intuitive, but attention to preventable risks is actually lean in the long run. See: BP, stupid maintenance tricks; and Air France 447, pilot training?

We all know about opportunity risks. That's either making a decision to take a risk, or planning a risk response for an opportunity already being exploited, or estimating a risky outcome for something we've elected to do. ISO 31000 and the PMBOK Chapter 11 cover this ground pretty well.  So does Edmund Conrow.

The thing about threat management is that there's too little attention paid to upkeep and maintenance of things that are supposed to work (infrequently and under stress) and there's too little attention paid to readdressing assumptions, environment, etc. Perhaps the countermeasures aren't even relevant anymore. How do you know?

So, perhaps the thing that's new here is the rearrangement of the dots which brings about an alternate narrative. That may be enough to make this framework worthy.






Bookmark this on Delicious

Process is a child of scale;

When your playing small ball, you don't need a lot of process. Just put them all in a room, close the door, and shove pizza under the doorway every few hours. Apply a little bit of heat, and then wait for results.

But, if you are playing with other people's money (OPM) and you are doing something that isn't trivial, then you need some process.

---

Process is a child of scale; that to have the latter inevitably brings the former.

And so what's a process? For sake of discussion, let's call it a transformer: Put something in; grind a bit; and whatever you put in is dramatically transformed into something wholly different. It's almost as if "miracle occurs here!".

Money, time, effort goes in; stir with a few steps and controls and policies, and there it is: DONE deliverables!

But transformers are tricky devices, suitable only for adults who think critically. There need not be more transforming capability than is necessary to get the results. That's where the scale thing comes in: larger scale, more at stake, more investment in process. And a little feedback is necessary to stabilize the process; in other words: no open loops!

One project I was on did something remarkable that I've come to appreciate: each new thing we did was preceeded by a process briefing. Someone got us all together in the war room; a one page map went up on the screen, and we stepped through it. Something of a dry run. Sometimes, we did some real-time editing; always we went around the room for concurrence. Did we have a "green board" and we could proceed? Or, did we have to bring someone along?

It's a great thing when a plan comes together. And, come to think of it, it's swell to have a plan, a process, a roadmap...whatever you call it, but it's the guidance for the whole crew.

And, more scale, more people involved, more attention is paid to the network, the workflow, and the validation.

And, more pizza!

Image: http://3bblognews.blogspot.com/2010/09/pizza-and-reading-yummy.html

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Best value: the concept

I recently had a short debate about "best value" versus "best effort. It's always important to be clear about terminology--words are important--but it's most important to get these ideas clear when it comes to Agile, because 'effort' and 'value' really aren't the same:

In Agile, the grand bargin with the project sponsor is to deliver "best value" at a fixed cost in trade for latitude to evolve the scope details. The concept is like pick of the litter: "the most valuable deliverables" from among all the possible deliverables.

Of course: who says it's "best"? Answer: the customer, or the one holding the customer's proxy.

At each iteration, the customer goes through the backlog and reprioritizes and may invent new things. New things are all put in a backlog stack. The totality of the stack is compared to remaining time and budget. (Mix in a little technical debt to add seasoning to the backlog) At some place in the backlog stack you draw the line--actually, the line gets redrawn at every iteration if anything changes, which it will. Above the line, things get delivered; below the line: there's always V2.0!

At the end of the project, the customer has picked the best value from the backlog. Anything not done is of lesser value than those that were picked.

So what's best effort? Best effort has been around a long time. All cost-plus-fixed-fee (CPFF) contracts are legally 'best effort'. The contractor's responsibility is to apply best effort to the defined scope (defined by the customer in the SOW and specifications); if it doesn't get done, then the sponsor has a decision: bring more money, or terminate the effort. The contractor has no obligation to finish on his own dime.

To the uninitiated, best effort sounds crazy, but actually it works quite well to get difficult jobs done; but it's not the same bargain as made in Agile. The best effort bargain is to bring the best and brightest to the problem and work as responsibly as possible, but at the end of the day, the sponsor is on the hook for the money to finish.

So, where's the rub? It's in the opportunity cost. For the contractor, the fee (profit) is fixed; the contractor can't get richer on a better job, nor poorer on a bad job. In other words, it's economically regulated from the contractor's point of view. Nobody can get "Facebook rich" on best effort like they could on best value.

Bookmark this on Delicious

Agile and US Federal Government

During one of my recent agile project management classes, a student contributed this posting:

[For acquistions sponsored by the] Federal Government, all systems--especially if they deal with life or death or classified data--have to receive an Authority To Operate (ATO) signed by a Designated Approval Authority (DAA)......

 

  

The National Institute of Standards and Technology (NIST) establishes the cyber security guidelines that all federal agencies have to follow. Each agency then tailors these guidelines to meet their particular needs. There is an extensive amount of documentation that is reviewed during the C&A process including the results of security testing.

 

  

• System Security Plan
• Risk Assessment
• Security Test & Evaluation Plan
• Security Test & Evaluation Report
• Continuity of Operations Plans
• Business Impact Analysis
• Privacy Threshold Analysis (PTA) and/or Privacy Impact Analysis (PIA)
• Rules of Behavior (privileged)
• Rules of Behavior (end-user)
• Security Assessment Report (SAR)
• Configuration Management Plan

 

  

.... The way this is handled within my customer’s agency is:
Sprints are generally 4-6 weeks long and produce a package of functionality, multiple sprints create an iteration, and multiple iterations create a release.

• The release can take anywhere from 3-6 months. The release goes from the product development organization to a separate release management organization which is responsible for coordinating the release of the product into production.
• The release management organization coordinates the C&A activities with the security organization.
• All these organizations are under the CIO but operate pretty independent.

 

Most of the actual development is outsourced to private industry so there is a varied role of the government staff in the Agile process. Since a lot of what the government staff does is contract oversight, the most likely role is as Product Owner Representative.

• The actual Product Owner is outside the CIO organization in one of the agencies business areas.
• For each project, the agency has created an Integrated Product Team (IPT) which has agency representatives from the business area, security, release management, architecture, etc. The project manager generally leads the IPT.
• I see the government project manager being heavily involved in developing the Product Backlog and to a overseeing the development of the Sprint Backlog but it is really up to the contractor to manage each Sprint.

[....]

 

It is a really interesting challenge to figure out how to take this agency to a more Agile environment. Not only is it helping them with the technical issues of implementing Agile but also with the biggest challenge which is the culture and organization change issues. Agile will have to be implemented incrementally over time and the agency may never reach a full Agile state. We are working with them to identify and implement those pieces of Agile that will provide the most benefits first and then continue the improvements.

 

[... ] The areas of the life cycle that I am trying to better understand are in
(1) project definition and approval,
(2) establishing the system architecture, interfaces to other systems, and data base architecture, and
(3) system level testing during a formal release cycle especially when there are major cyber security concerns (classified data, life or death considerations, financial data).

Much of the Agile training assumes that the project has been approved and is ready for coding; does not address a formal release cycle; and focuses at the team level.

 

I have started to review “Agile Software Requirements” by Dean Leffingwell which discusses the Agile Enterprise Big Picture and presents a scaled Agile delivery model at the team level, program level, and portfolio level which provides additional background.

Bookmark this on Delicious

Innovative construction

Silly me. I actually didn't know that there is a whole industry around something called "accelerated construction" in transportation projects (roads and bridges). It seems like these program guys have come up with the ultimate schedule fast-track.

I stumbled on this reading about fast projects for bridge construction. It turns out, there's a lot of them. And the reason seems to be economics (no one has any money) driving fast (read: cost efficient) solutions, or perhaps solutions (read: new methods and technology) making it economical. I'll leave the chicken and egg argument for someone else.

Nevertheless, accelerated construction is a project phenomenon that is being moved along by these factors:

• A US federally funded Accelerating Construction Technology Transfer (ACTT) Program
• Pre-fabrication (nothing new, but part of the plan), and
• SPMTs (self-propelled modular transporters) which are multi-axle, computer-controlled platform vehicles that can move bridge systems weighing up to several thousand tons with precision to within a fraction of an inch. (Let's hear it for GPS!) The vehicles can move in any horizontal direction and also have vertical lift.

Now, down here on Florida's space coast, we know a thing or two about large scale transporters: after all, moving the space shuttle around was no small matter

But, in the bridge business, having the right transporter technology is perhaps the one project tool above all others that makes the rapid schedules workable.

From the US Federal Highway Administration website, we learn a few case studies:

• Sam White Bridge over I-15 in American Fork, Utah - In March 2011, the Utah DOT (UDOT) used two sets of SPMTs to lift the Sam White Bridge across eight freeway lanes of I-15. This was the longest two-span bridge ever moved by SPMTs in the Western Hemisphere and was UDOT's 23rd use of the technology.
• Massachusetts FAST 14 Project - The use of accelerated bridge construction, prefabricated bridge elements and the design-build project delivery method enabled the Massachusetts DOT to shrink a four-year bridge replacement project to just one summer. The $98 million project, dubbed "Fast 14," involved the rapid replacement of 14 deteriorated bridge superstructures along I-93

In a few words: bigger is usually better! Let's hear it for transporters.

Bookmark this on Delicious

Unmanaged risks

On any project there are going to be dozens, perhaps hundreds, of unmanaged risks (I doubt this is news to anyone):

• Weaknesses that are Low-Low on the risk register's probability-impact matrix, maybe even all the way to High-Low (p-I)
• Threat events or their effects that are off baseline, not in the project plan, and range from Low-Low to High-Low, perhaps even Low-High also (p-I) 

So, you've not put the unmanaged event or its effects in the project plan, but you have identified the risk and put it below the line of those risks that you will actively manage. Among the four big strategies--accept, avoid, mitigate, and transfer--which one is being used in this management scenario?

If you picked "accept", you get the risk manager's prize for this posting. Indeed, this is 'acceptance' of risks that are below the line and not being managed.

Frankly, for many, the idea that we're going to sit back and accept risk is an uncomfortable position to take. But it happens all the time. When my risk management students lament that their organization has no risk management process or strategy and just deals with risk as they come along, I respond:

"No strategy" is a strategy of sorts in the sense that you've embraced "accept" as your risk response plan. In that event, the need to actually do a lot of work up front to identify risks is really not too productive. If the organization is risk-seeking in attitude, this may be just fine. After all, you're just going to accept whatever comes along and deal with it.

Now, assume one of the unmanaged risk events occurs, and there's some effect to the baseline; now the risk is an issue (issues being in the present, and risks being in the future). Now, you manage the effects of the issue. Is there anything you should have done in the plan, anticipating that your strategy is more about issues and less about risk?

Actually, yes: if your target is issue management and not risk management you can still take a page out of the RM manual to prepare:

• Maintain a vigilant 360 awareness to give you some runway on issues
• Keep your powder dry by holding back some unallocated reserves
• Buffer the schedule in the areas you predict are key to project success
• Keep conjunctive events at a minium (planning strategy)
• Have a good idea in mind of a conflict resolution process that you can bring to bear during issue debate and resolution

Does all this mean that unmanaged risks are actually part of the plan and you're just deferring the inevitable? No, unmanaged risks are just as uncertain as anything being managed. Some will happen; many will not. But letting them become issues rather than managing them as risk, you've limited your options in two ways

1. The runway is shorter than it need be
2. Risks that could have been avoided may not avoidable

Seems a little short-sighted, but no risk strategy is a strategy

Bookmark this on Delicious

Are you on LinkedIn?    Share this article with your network by clicking on the link.

What's that agile thing?

Every agile discussion is dominated by two questions:

1. What is agile;
2. Why agile?

The first question is answered this way:

Agile is a name given to a number of different methodologies that are all responses to the answer to the second question. Though agile methodologies differ in many respects, they are composed of both management practices and technical practices.

These practices are not too much different than those we know from the PMBOK. However, they are arranged in unique ways, given different priorities and names and relationships, and so the project management narrative is quite different even though the constituents may be familiar.

In effect "old dots connected in new ways" = new narrative, but the new narrative is why agile is effective.

The second question is the more important:

Agilists say that the predictability offered by traditional methods is a myth, that predictability is not really possible. Predictability of cost, schedule, and scope is problematic because of these two reasons:

1. Requirements paradox: we want requirements to be stable; but (user) requirements are never stable. But, other non-user requirements taken from standards, infrastructure specs, and the like can be, and usually are, stable. So, requirements are like a layered structure: the bottom layers are usually stable; it's the user layer that's not.
2. Systems (of requirements) have chaotic and emergent properties, actions, reactions, and functions/performance. These emergent actions and reactions are simply not predictable; they can only be experienced. Once revealed they can be dealt with.

Agile deals with these two problems these ways:

• A bargain is struck with the project sponsor (call this a business case): in trade for the flexibility to handle user requirements as evolutionary and emergent, agilists pledge that they will deliver the best possible value (not a specific scope) within the time and budget given by the sponsor.
• Requirements (in the form of stories) are discussed conversationally with developers. When understanding is reached, the conversations are then frozen in time boxes and developed to the point of DONE; then the backlog is unfrozen, a new batch are selected, and 'do again, until ...' ("Done" may be an alpha release, a beta release, a prototype for a focus group, or a production release)
• Estimation depends on benchmarks of past performance on similar stories.
• Time box performance by teams depends on the teams sticking together and practicing together so that their performance over the duration of a timebox is predictable.
• Users exercise the system to tease out the unpredictable; these then become 'debt' in the backlog, to be prioritized with other requirements
• Verification is done incrementally; validation is only done at the project epic narrative level

Bookmark this on Delicious