Posted by Glen B. Alleman on May 25, 2012 at 02:41 PM in Risk | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The term risk is tossed around way too easlily these days. Just like we toss around complexity, complex, or those other terms that have self induced confusions - leadership versus management, complex versus complexity, coaches versus mentors, responsibility versus accountability or agile versus lean. When we assume - wrongly that definitions don't matter, we're just being lazy.
So back to risk. First of all risk is based on uncertainty. There are two types of certainty
We must distinguish between these two types of uncertainty when starting our probabilistic risk assessment for project work. The next understanding is about probabilities.
"probability is fundamentally the same concept regardless of whether it appears in the model of the worldor in the subjective distributions for the parameters. There is only one kind of uncertainty stemming from our lack of knowledge concerning the truth of a proposition, regardless of whether this proposition involves the possible values of the hydraulic conductivity or the number of earthquakes in a period of time. Distinctions between probabilities are merely for our convenience in investigating complex phenomena. Probability is always a measure of degree of belief."
In, Mosleh, A., Bier, V. M., and Apostolakis, G. (1988). A critique of current practice for
the use of expert opinions in probabilistic risk assessment. Reliability Engineering and
system safety, 20, 63-85.
So How Do We Manage In The Presence of Uncertainty
This first thing to do is NOT assume that the system is emerging in a random manner. That notion provides no support for those funding the project. We must have a PLAN to determine is the project is headed in any direction that will result in it be DONE in any form acceptable to those providing the money.
So we need to start by answering the question what is the probability of some future event. The notion that we can't ask and answer this question is one of those other nonsense concepts. Of course we can ask and answer. You do it all the time. What's the probability of rain today is answered by loking outside or maybe looking in this mornings paper, or even on your Android at weather.com.
Our first step is to not try to manage the Aleatory Uncertainty but to understand the probability distributions resulting from this uncertainty and manage in the presence of this uncertainty.
What's the probability of completing on of before May 3rd, 2013? Good question. What uncertainties are in the current schedule? What's the probability of this projects costing $136M or less on or before May 3rd, 2013? Good question. What uncertainties are in the Basis of Estimate?
Next for Epistemic Uncertainty, we must discover what we don't know. This is called mitigating the risk or buying down the risk. This is one way Agile is connected to risk management. Let's build this gadget and see what happens. From that we'll know more and can remove some of the risk when we build the real thing. This by the way is called prototyping - Dah, been doing that for centuries, don't know software development didn't figure that out.
As an aside there is another approach using Evidence Theory, for managing in the presence of risk. This approach requires more advanced understanding of the project attributes, so for now the approach described here will be the starting point.
Just as an aside
There are differences between terms, this is why we have dictionaries.
One of my favorites is Accountability versus Responsibility. We use a Responsibility Assignment Matrix (RAM) on our programs. It is required by the ANSI-748-B Guidelines. It states who is doing what. But Accountability is not the same as Responsibility. The Accountable person is just that singularly accountable for the outcome. The person - the single point contact for making things happen. No group accountability. The group can share responsibility. But only one can be accountable. This is a notion not well understood in many domains.
Agile versus Lean - ask the Agile and Lean folks for the difference. They are distinctly different at their core. Lean manufacturing may contain some agile processes. Lean Aerospace defined at the Lean Aerospace Initiative is now called the Lean Advancement Initiative.
Management versus leadership - read the US Army Field Manual FM6-22 titled Army Leadership, Competent, Confident, Agile. Notice FM 6-22 is about agility on the battlefield, interesting? Wounder if all those agile management "leaders" have read how real agile leadership works when lives are at stake?
Leadership is the process of influencing people by providing purpose, direction, and motivation
while operating to accomplish the mission and improving the organization. Management is about the processes used to lead. There can be managers, but they most likely follow a process.
Complex versus complicated has nice clean, well established dictionary definitions. I know there is a tendency to make up new words and claim credit, by read Beyond the Hype to see that it's generally a bad idea.
So in the end the Program Manager is Accountable for managing in the presence of risk. The PM can have others Responsible for managing the risks - the Risk Manager. But in the end when the launch vehicle blows up on the launch pad, it's the Program Manager who is accountbale. Our when JP Morgan looses $2B is a risky trade it is Jamie Diamond who is accountable.
Posted by Glen B. Alleman on May 24, 2012 at 11:59 PM in Risk | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Lately there have been several voices that resonant with my World View. Ronald Regan's "trust but verify" is a phrase many times forgotten in our project management and process improvement world. I came across Carol Deckers through a twitter reference from Dan Galorath. Dan provides estimating tools used in our aerospace and defense world and other places like enterprise IT.
The notion of "trust but verify" is close to show me you can produce what you claim you can produce. In the management processes applied to our programs, we start with the Federal Acquisition Regulation, which is essentially based on "trust but verify."
So we're back to the core issue
When an initiative is suggested we need to Trust there is a credible outcome. Otherwise, we'll be spending all our time worried that it won't work. But this trust has to be based on something real:
And we need to verify
This is the source of my constant suspicions around 2.0 and 3.0 effort from individuals with ancedotal experiences and a good publisher. This happens about once a year for the past decade or so. First was Project Management 2.0. The old project management processes were failing. Turns out the project failures for the most part come from failing to follow the old project management processes. I loved one of the suggestion of PM 2.0 that social media was the answer to better project management. Yea let's manage out projects with Twitter. This BTW is the antithesis of agile, where face-to-face is the starting point.
Then the hordes of new and innovative business and change management processes. SoI always start with Beyond the Hype approach to assessing the suggestion. I know some will say you're way to conservative here, You'll never make progress with that attitude. Well we manage other peoples money when managing our programs, so yep you're right.
Posted by Glen B. Alleman on May 23, 2012 at 11:44 PM in Management | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The answer of course is a resounding yes. If we can calculate something we don't have to rely on hand waving, references to populist articles that do their own hand waving, or at least references to dead people who did the hand waving before.
The very notion that a stranger is going to spend good hard earned money to make changes to something that actually belongs to someone else - possible share holders - in the absence of some sort of verification that that hard earned money is going to get returned some time in the future - is well - out of their freck'in mind.
This approach to social systems is based on the belief there are enough people out there who don't have the accountability to the share holders, a contract officer, a government procurement officer, or someone themselves accountable to look after the money, is common. It's common because those getting really excited about changing the world aren't always the ones accountable to those pesky shareholders and contract officers.
That's not to say the world doesn't need changing, because it does. The world needs people who expect it to change from their own ideas. The world needs people who come up with completely new ways to make things happen. But the world is also a cruel task master when it comes to funding these ideas. Ideas that a cheap when they don't involve spending money.
Like getting together at Starbucks to scheme on how to do things better. Like let's fix our status meeting process. That doesn't take much money, just effort. Or let's restructure our organization and not focus on earnings per share instead focus on having harmony among the product development teams first so we can improve EPS sometime in the future. Ah, you'd better have the CFO, CEO and Chairman of the Board, and the Investor Relations VP at Starbucks before you jump off that cliff.
Without some notion of the credibility of the idea of how to change anything, it simply doesn't happen. This of course doesn't stop people from trying, never has, never will. But being cranky and disappointed should not come as a surprise - change is hard.
There is a critical difference between something being possible and something being possible. It may be possible to change to world but is it probable in the domain and context you work. If not probable, it's best to look for work somewhere else.
Posted by Glen B. Alleman on May 22, 2012 at 10:04 PM in CAS, Management | Permalink | Comments (4) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
There are nearly unlimited sources of advice on how to make improvements to nearly anything we could imagine. Not just personal improvements, but business improvements, management improvements, project improvements, technical improvements, world improvements.
I have a bias here shared by many of my colleagues. This bias stems from our domain, for the simple reason, we work where measurement dominates the conversation. We share a World View that performance performance improvement or even performance sustainment starts and ends with measuring things.
Measurements we'd find in the work we do, include but are far from limited from some basic questions that very person accountable for spending someone elses money must ask:
But that are other measurements in our domain too.
These questions come about because we work for people who spend either their own or other peoples money. If you're spending your own money (not someone else's) the importance of these questions is less, maybe even nonexistent. It's your money, spend it as you please. But the people that hire us almost always spend someone else's money. Many times they spend the money of a sovereign - the governments money.
The starting point for a look into this world of being accountable for other peoples money, is the book Making the Impossible Possible: Leading Extraordinary Performance, The Rocky Flats Story. This title contains the essence of our World View - Heliotropic Abundance and Positive Deviance and how Complex Projects in the presence of complexity, are managed using this paradigm.
When we say complex projects (or programs) and management at the same time, there is a specific set of meanings to these words. These words are based on Systems Engineering paradigms and the complexities of systems. System is defined in the context of a product or service provided to the people whose money is being spent. Of course this system has boundaries, relationships between its components and of course the relationships between the people working to produce the system or working in the system to produce something.
And also of course the system includes the people building the product or service. But it is the product or service that comes first. Otherwise why are we spending other people's money. Certainty not to increase the self actualization of the people working on the system. That may be a by-product, but rarely do strangers pay us to increase self actualization of our staff. You had pretty much better come fully funtional on the self-actualization front, before starting work on our programs.
All systems - at least all non-trivial systems - have complexities. They may even be complex. There is a science context for these words and a business context as well. In the domain we work, disorganized complexity is rare, for a simple reason. The firms we work for would have been eliminated from the gene pool if they could get the disorganized complexity under control. The systems we work are complex and have complexities.
Now We Get to the Hard Part - and there is Always a Hard Part
In the domain we work, we calculate things all the time. That's what we do, we calculate. We calculate Cost, Schedule, Technical Performance, Labor utilization, investment return, effectiveness of a process, effectiveness of people in their roles, effectiveness of the organizational structure and its behavior.
We calculate suggested ideas for improvement. We ask how would we know? How would we know the suggestion will actually going to work? How would know that the person making the suggestion actually has had success outside of personal experience? Is there are any tangible evidence that the suggestion is actually applicable to the problem we are facing?
So what happens when those making those suggestion don't have this evidence? Do we proceed? Maybe, maybe not. Remember it's other peoples money. We usually start by asking annoying questions - questions that we hope will produce answers in some unit of measure meaningful for our decision making processes
In the absence of these answers that have measures in them - numbers - we tend to lose interest quickly. This was the original problem with Agile. Just Try It works great when it's your money. When it's someone else's money, it's a bit more difficult to proceed with an experiment, without the full acknowledgement that it's an experiment.
When the problem to be solved is a people and organizational problem, the path forward in the absence of some unit of measure is more difficult. We need something that provides increased confidence that is we proceed it'll turn out all right. This can be case studies, reference processes, working prototypes. This is how Agile got going. Small examples of success, that started to scale. But Just Try It is probably not the basis of the decision.
So Here's The Suggestion
When you hear, read, or see a new and exciting approach to an existing problem, first buy and read Beyond The Hype. Then and only then, come back to the suggestion to see if those making the suggestion fall into the category of reprocessing ideas in a new language and passing it off as new.
Now there is great value in repackaging ideas. It may make the ideas clearer, more understandable. But usually anything that has a common name with a 2.0 or 3.0 behind the name should be suspect. Of course all thoughtful managers (or anyone for that matter) should be eager for and open to new ideas. They should also be just as skeptical that the latest sure-fire solution to what they realize are eternal problems that must be constantly managed, is just possible an old idea in new cloths.
They learn, either by instruction or by hard knocks that all suggestions must be actionable, measurable, and connected to tangible outcomes from the suggestions. It's that annoying measurement part.
So proceed with care. Beware of the Hype. Be-aware that problems are constant and pretty much unchanging. The same problems. There are rarely new problems, just old ones that have come back. New and innovative approaches to these old problems need to be tested. But while listening to the 3.0 version of the solution to the 1.0 version of the problem, ask some hard questions:
And don't listen to that Einstein quote about “You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew.” That was about general relativity and the missing math (Rieman spaces).
Remember - everyone lives by selling something (Robert Lewis Stevenson). Find what they're selling before you buy. Ask those pesky annoying questions about how can I measure what you're selling in units meaningful to me. Don't buy the Hype, buy the outcome.
Posted by Glen B. Alleman on May 21, 2012 at 09:37 PM in Management | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Kelly's Contemplation has a nice post on The 3 Phases of an Agile Project. He starts the example with receiving a project that has few actual requirements. The notion of a traditional - or better yet conventional - approach to project management starts looking for requirements. The agile approach is presented in a way that is typical of COTS based deployment through progressive development of the capabilities of the tool set tailored to the needs of the client.
Here's where traditional, er., conventional, project management fails to deal with the current approach to complex project, program, and product development.
I our Defense and Space program, there is a critical first step, that is baked into the procurement process.
CAPABILITIES BASED PLANNING
What capabilities does the customer want to posses when this project is over? These capabilities are the prerequisites to defining the requirements. Here's an end-to-end process for developing the capabilities description. This looks very non-agile, but these are the principles, put these into practice in a way that best suites your need. But check to see if you've covered off all the steps, because is something is missing, you may think you're being agile, but in fact you're missing a critical piece of data.
The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?”
Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer.
The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission.
The process flow above is the starting point for Identifying the Needed Capabilities and determining their priorities.
Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program.
In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means.
The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability.
Here are the details of how to capture the capabilties needed by the customer. Again do these any the way the best suites your need. But do check that you've got - or are going to get - all the information. Otherwise you get to do the work twice.
Notice that most everything talked about in the post is here, plus some other stuff. Trade offs between capabilities is critical. Assessing the costs and the risks. It doesn't do anny good to charge ahead with everything the customer wants to do if you have no idea of the REAL costs and the REAL risk that is being created by your agile approach.
But defined capabilities through Use Cases and Scenarios is the standard approach in large defense and space programs. There is even a language for doing that - SysML is a systems engineering modeling language for Use Cases and Scenarios. I know that doesn't sound very agile, but on a multi-billion weapons systems (mostly software these days) scenarios are the starting point for identifying the actual requirements.
This is the core concept missing from the PMI approach, the dreaded waterfall approach, the conventional approach. And of course these approaches are no longer allowed in the procurement of system for the Defense and Space industry. Those places procure systems using Capabilities Based Planning.
The picure above is one of 5 processes we use in our Performance Based Management activities in our domain. Next comex the requirements, since we're spending the governments money, they want to know those sorts of things.
Posted by Glen B. Alleman on May 16, 2012 at 08:49 AM in Agile | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
"Employ your time in improving yourself by other men's writings, so that you shall gain easily what others have labored hard for." - Socrates
But rememeber, you've got to provide attribution, otherwise they'll think you're a poser. Taking credit for others ideas as your own, or even embellishing them and calling it new is bad form these days.
Posted by Glen B. Alleman on May 16, 2012 at 08:04 AM in Quotes | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The notion of asking 5 Whys is part of Six Sigma processes in a variety of domains. Seeking the Root Cause, in a Root Cause Analysis, to standard practice in manufacturing and business processes.
In the Project Management domain, this concept is not so common. I've come to the conclusion that we're mission out on a critical success factor for increasing the probability of success from our efforts.
While participating in an Initial Visit between our client and the DCMA, the Six Sigma processes were described by the DCMA staff, which included DCAA for several parts of the 32 Criteria of ANSI-748-B and the 6 Business Systems needed for program success.
Here's an example of who to use the 5 Whys on your Project
We just got an invoice from Bob's House of Power Supplies, that we don't have a purchase order for. Bob claims he had verbal approval to build the power supplies on short notice and ship them Fed-X to the integrator.
In the end the process failed all around. The typical response is I went around the process because the process didn't provide me with the needed capabilities. But in the end emergency procurements are common, and there is a process, just not known.
Posted by Glen B. Alleman on May 11, 2012 at 06:51 AM in Project Management | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
This is my favorite quote around planning. Mike is an email colleague. We've never met in person, we've talked on the phone and extensively through email. This quote has been the basis of our extension of Capabilities Based Planning for the Program Planning and Controls practice. I use it every chance I get. It sums up the critical success factor for program improvement as well as the critical missing piece for most project failures.
Without a plan that looks into the future for emerging solutions, you'll simply be one of the bad project management examples the agile folks love to quote.
This in no way means you don't follow the plan, but the plan itself has to adapt to the emerging situation. The very notion that you would not respond to change and update the plan is simply nonsense.
Have a Plan, confirm it's the right plan at periodic points, follow that plan. When there is a change of plans, assess the impact of those changes, and make a new plan.
Plans are mandatory. Make one, follow it.
Adapt the Plan to the emerging situation.
Without a Plan you'll never know what DONE looks like.
Ignore that silly advice of respond to change over following the Plan
If you respond without a change in plans you're lost and will not recognize DONE when it arrives.
Posted by Glen B. Alleman on May 10, 2012 at 07:37 AM in Planning | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
What phyiscs tells us about the universe is it's big, rare events happen all the time including life, and that doesn't mean it's special.
- Lawerence Krauss's letcure on Dark Matter and the reason for the universe
Posted by Glen B. Alleman on May 09, 2012 at 08:38 AM in Quotes | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
I'm working on proposal for deploying agile in a federal agency. They have a need to integrate Agile on the development of standard business systems. The first steps are to determine what existing software development processes are in place, what processes can be introduced, and what processes are imposed by the Federal Acquisition Regulation on their set of programs.
So now the real issue. This is not an environment where we can experiment with other peoples money, since that money belongs to the United States of America.
By Battle Tested, I mean a method that has survived the engagements of actual battle in developing software in the current paradigm - federal acquisition. There are many proponents of agile out there who have all kinds of suggestions. A classic suggestion is celebrate learning, not success or failure.
In this celebration approach, who pays for those learning processes? The citizens of the United States of America? Probably not. This notion that we get to experiment on other peoples money, is unique in the domain I work. The domain of being the fiduciary of other peoples money.
It's fine if your spending your own money, or you have written permission to experiment with other peoples money. No problem. Do it. Write up the results, so the analysis of how your experiment might be extended to other domains and contexts in those domain.
But there is this really annoying little problem with spending other peoples money and then trying our new ides.
Do you have any evidence what so ever - beyond personal anecdotes - that your idea will actually work in the current situation?
No? Then maybe you should try it out on your own money, do some peer reviews, have someone elses try it out on there money, do some more peer reviews, then get someone to fund the experiment to see if this wonderful idea actually does work outside your own personal experience.
I know is an annoying, very annoying approach. But when we're assigned to help out and the money needed to do that work comes from a sovereign or a board of directors, it's just that we have an obligation to actually improve the situation, not just use that money to celebrate our learnings.
Unless we got paid to learn something, we probably should show up with a solution in hand. A solution that has worked in several, if not many, similar domains and contexts. Annoying I know.
Posted by Glen B. Alleman on May 08, 2012 at 08:01 AM in Agile | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
An interview with Jeff Sutherland and Hank de Velde brings up some important notions in program and project management.
But there are some critically important aspects here that if ignored will lead to utter failure.
Both Jeff and Hank
During a short email conversation with Jeff to determine if we were in country at the same time in the late 60's and early 70's in Vietnam - we weren't - we confirmed that our training, supervision, experiences, and learning opportunities have informed our seperate paths. Jeff's with Scrum, mine less famous with our Integrated Master Planning and Performance Based Management, share one critical thing...
Management in the presence of uncertainty - a matter the domain - requires past experience to avoid failure.
This concept is many times lost in the zeel of deploying agile develoipment or any version of lite.
There is a saying in the military flying business
There are bold pilots and old pilots, but there are rarely old bold pilots
Past performance informs future behavior. Jeff didn't drive around the skies of Vietnam without first having extensive training, the inherent skills to put that training to work, and the seat of the pants experience in the log book to know when to take risks and when to play it safe, or when to stick to the plan and when to come up with a new plan real quick, because an unplanned event just appear in the windshield.
While there are many quotes about planning and plans not surviving the first encounter with the enemy, never is that planning process abandoned in the presence of a disruptive event. It goes like this from actual cockpit experience.
The Agile Mainfesto and Planning in the presence of reality
What This Means in the End
Posted by Glen B. Alleman on May 07, 2012 at 07:45 AM in Planning | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Posted by Glen B. Alleman on May 03, 2012 at 10:05 AM in Blog | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Just finished reviewing my notes from a DAU course on Earned Value and the validation of Earned Value Management Systems (EVMS). In the first hours of the first day, there is a slide that admonishes the students to:
This is because many times terms are used interchangeably and many times incorrectly
For programs applying Earned Value Management
Who Cares?
Here's why. There are many voices out there how misuse these words. Some are well placed voices, working for brand name computer firms, with platforms that people listen to.
The classic is the complaint that EVM can;t be used on IT projects because it does not measure business value produce by the project. This of course is not only wrong - see the third bullet - it is uninformed. Because of this misinformation, there is now a group of software developers that have come to believe that EVM is not the right tool, simply because of this serious mistake in understanding.
So Here's The Replacement
Earned Value Management is a close fit with the development of software in the agile paradigm. Planning the outcomes in a planning session, assigning costs to the development of the outcomes with the Budgeted Cost of Work Schedule (BCWS) is simple - how may people do you have on this iteration? How much do this cost your firm? How many hours for the iteration x (Salary + Overhead + G&A + Fringe + Cost of Money)? This is your budget for the work that is to be performed.
Someone has to pay. Your firm pays if it is an internal project. Your customer pays if it is external.
What's the schedule - the period of performance for this work? In agile (Scrum) it is the duration of your iteration, the release cycle, the epic, or what ever you want to call the longest period of performance for your work efforts.
Now the reason for Earned Value Management
When the number of story points is defined in the planning session, these might be considered the measure of physical progress to plan, so let's consider them so for the moment. As the iteration progresses, these story points are earned when they result in 100% Physical Percent Complete - the perfect agile term - Working Software (according to the definition and units of measure of working).
The formula (the simplest one) for Earned Value is EV = BCWS x Physical Percent Complete.
In the agile world the Physical Percent Complete is either 0% or 100% for each story and its assigned Story Points. This notion of defining the value the Earned Value up front and then earning it is both an Agile notion and an Earned Value Management notion. What is missing from the Agile notion is the Budget for earning that value. But not problem, almost all Scrum teams have fixed resources assigned during the iteration, so the budget is the number people times their burdened cost.
In the End
Ignoring for the moment the notion of AgileEVM, EVM Lite, and any other made up term - there is ONLY EVM RIGHT - the principles of Earned Value Management are universally applicable to all projects, for the simple reason that project management performance measurement is about:
Earned Value Management is about measuring physical progress to plan. It is a natural process of iterative and incremental development. Don't let those supposed experts tell you otherwise. EVM is not about measuring business value. That's another measurement - usually a Capabilities Based Planning, some form of business modeling, or even a monetized Balanced Scorecard approach.
Earned Value Management is about measuring the performance of your development work in units that are meaningful to the decision makers. Story Points have no unit of measure meaningful to the decision makers. Consumption of money is meaningful, Story Points are just an ersatz representation for money.
Posted by Glen B. Alleman on May 02, 2012 at 10:47 AM in Earned Value | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Any system that claims to measure perform of a project needs to provide:
Posted by Glen B. Alleman on April 30, 2012 at 08:29 AM in Management | Permalink | Comments (1) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
The jawbone of an ass is just as dangerous a weapon today as in Sampson's time.
--- Richard Nixon
When we encounter bad management and then construct an alternative to correct, without first assessing how to stop the bad management so we can find the real problem preventing a good outcome, it's called argument by false analogy.
I've seen bad management produce bad outcomes, so my approach to that bad management will produce good results.
This is a common approach in the replacement of bad project management by alternative management processes.
The managers of our firm so badly apply the PMI principles to our projects, that we need to switch to agile software development to fix our projects.
A similar approach is:
Our managers have applied management practices so poorly, we need to abandon the known principles and replace them with new and likely untested outside of personal anecdotal experience.
In the debate and forensics domain, this is called false analogy. This is seen many times, when the basis of the argument starts with anecdotal experience - it worked for me and a few of my friends, so it'll work for you.
Posted by Glen B. Alleman on April 23, 2012 at 12:30 PM in Project Management | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Earned Value Management is a method of measuring the performance of work efforts that have been budgeted and the work planned in a time phased manner.
Earned Value should be named Eraned Budget - you earn your budget for the work.
Why is Earned Value unique in the world of project management?
Applying Earned Value is simple
With these numbers calculate the Earned Value for the work performed to date:
With this result - the cost variance and the schedule variance - you can now forecast the future performance of your project. This means that when someone asks how are we doing? Or asks, when will we be done? Or even better, how much will this cost when we're done? You can answer with a definitive set of numbers in units meaningful to the decison maker.
Numbers like:
These types of answers are not available, when you measure progress to plan with the passage of time and consumption of money. While agile suggests that it is doing Earned Value, it does not measure the cost of doing the work, nor does it measure the pre-defined phsyical percent complete in units of techncial performance.
Earned Value provides you with insight into the physical progress to plan, in units of measure you can use to make adjustments to the project to keep on schedule, stay on budget, and provide visibility to the increasing maturity of the products or services your project is delivering.
Here's the next level of understanding Earned Value in Five Easy Pieces.
Posted by Glen B. Alleman on April 23, 2012 at 08:23 AM in Earned Value | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Which comes first?
Let's start with Jon Katzenbach's definition of a team. Katzenbach is a recognized leader in counseling high profile CEO's and their staff - the business teams that are at the heart of corporations. His book The Wisdom of Teams was a seminal work for me when I led some of the teams working a large and very complex Department of Energy program.
What struck me, and has never left, is the core confusion of how many in the agile world start with the social aspects of project teams.
First there is another core confusion revealed by Katzenbach.
If you are on a team, who is your opponent?
I played collegiate volleyball. That volleyball team had opponents. Other universities. University of California, Irvine, versus University of California, Los Angeles. Our team had a clear and concise of the outcome - beat UCLA (it rarely happened). But no member of the team was on the team for the social aspects as their first goal. We were all there to play competitive volleyball. While there are a dozen or so members of the UCI Volleyball team, teams can be smaller. The rowing teams that practice on the Boulder Reservoir in a 2 man scull are a team. They are also on the larger team of all scull's - single, 2 man, and 4 man - women as well.
So Katzenbach's definition helps clarify how teams that are formed (paraphrased)
A team is a small group of individuals who hold each other accountable for a shared outcome.
For teams to be successful, we need individuals, accountability, and a shared outcome.
The social aspects of the team may or may not result from the individuals, accountability and shared outcome. The social aspects don't have to have these attributes.
What I've observed over the years, both in my teams, and or now college age children is a migration from the outcomes first paradigm, to the friends and social aspects first. Good for them. But I'm waiting to see how well this turns out in practice.
If the first condition is to form a social unit, that is stable and has an identity, can they actually get the job done. Having a shared outcome as the starting point may allow the team to ignore the social aspects until there is evidence that the shared outcome and the mutual accountability are in place and the members actually want to participate in the social part of the team.
On the volleyball team, the mutual accountability was in place. It had to be in place, or we would not play well. But the social unit was nice, but not necessary. It was - and is - the mutual accountability that was the basis of success.
So 3 people working together for 2 months is a Team if - they have a shared outcome and hold each other mutually accountable for that outcome.We can have a team of golfers playing in a tournament on our course. We can have a spring clean up team at the park. If they are holding each other accountable for a shared outcome. Win the scrable or clean up the winter branches.
Remove the need for the social, stability, and identity as the first condition. The team is still there, it's doing its work for that period of performance, and most of all they are holding each other mutually accountable for that work.
Social, stability, and identity are all very nice outcomes. But they are not the core conditions for success of a team.
When those shared goals start appearing, and the mutual accountability is working, the social, stability, and identity come naturally as a result. The other way around may not produce the same result, simply because the shared outcome - the teams goal - is not based explicitly on mutual accountability.
Posted by Glen B. Alleman on April 20, 2012 at 08:22 AM | Permalink | Comments (8) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science — Lord Kelvin
When we contrast that with Einstein quote
Not everything that counts can be measured. Not everything that can be measured counts.
We need to ask what is the context and domain of the measurement. If you're accoutable to the stockholders of investors, maybe you want to consider measurement as a starting point for your success.
Posted by Glen B. Alleman on April 18, 2012 at 08:50 AM in Quotes | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|
Cost variances on projects come from a variety of sources. Here's a picture of some of the drivers that are common in many domains.
The management of projects means you have to address these and many other activities to answer the questions posed by 5 Immutable Principles:
These impacts on cost variance are part of principle 1, 2, 3, 4, and 5. They are part of all the principles, because without a credible understanding what the project is going to cost in the end, the management processes of the project itself are no longer credible. You're then just spending other peoples money with no connection to producing value - yes the business value.
Posted by Glen B. Alleman on April 17, 2012 at 12:31 PM in Cost | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
|



Recent Comments