Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Herding Cats - Glen Alleman
Syndicate content
Performance-Based Project Management¬ģ Principles, Practices, and Processes to Increase Probability of Success
Updated: 12 hours 56 min ago

Quote of the Day - Plan for the Future

Tue, 09/16/2014 - 01:05

Before you begin a thing remind yourself that difficulties and delays quite impossible to foresee are ahead. You can only see one thing clearly, and that is your goal. Form a mental vision of that and cling to it through thick and thin.
‚ÄĒ Kathleen Norris

Screen Shot 2014-09-15 at 3.58.10 PMAnd when they are impossible to see we need margin and reserve to protect our project from them. This margin is for the irreducible risks and the reserve is for buying down the reducible risks. Both irreducible (aleatory) and reducible (epistemic) uncertainties can be modeled for all projects. This is the role of risk management and project. To NOT model these uncertainties is to ignore them. To ignore them is to say to those providing the money that you're not following Tim Lister's advice...

Risk Management is how Adults manage projects

As well when you begin a thing remember another important quote...

Measurement is the first step that leads to control and eventually to improvement. If you can‚Äôt measure something, you can‚Äôt understand it. If you can‚Äôt understand it, you can‚Äôt control it. If you can‚Äôt control it, you can‚Äôt improve it. ‚Äē H. James Harrington

So if we're going to start a job and don't have an assessment - to some level of confidence - of how long it will take, how much it will cost, and what we will be capable of delivering when we get to the end of the money and the time - it is very likely that those paying for our work will be very disappointed in our efforts.

When we here that we can make decisions in the absence of knowing the probabilistic cost, schedule, and likelihood of producing the needed capabilities, think back to the two quotes above. And consider the conjectures below that requires us to ignore those quote and instead follow those statements in the absence of any evidence they are applicable outside of the Value at Risk being low enough that those providing the money don't really care if it's all a loss.

Workshop

† Orginal post from Mark Anderson's email from ExecuNet, 9/14/2014

Related articles Uncertainty is the Source of Risk The World of Probability and Statistics How to Deal With Complexity In Software Projects? Both Aleatory and Epistemic Uncertainty Create Risk Time to Revisit The Risk Discussion
Categories: Project Management

GAO Reports on ACA Site

Fri, 09/12/2014 - 19:08

With all the speculation on what went wrong with the ACA site and all the agile pundits making statements about how agile could have saved the site, here's some actual facts beyond all the opinions - that Daniel Patrick Moynihan would remind us...

Every man is entitled to his own opinion, but not his own facts

 

  Screen Shot 2014-09-12 at 11.40.52 AM

and

Screen Shot 2014-09-12 at 11.42.53 AM

The Key Findings are

  • Oversight weakness and lack of adherence to planning requirements.
  • Acquisition planning carried high levels of risk.
  • Requirements for developing the FFM were not well defined.
  • Contract type carried risk for the government.
  • New IT development approach was supposed to save time, but carried unmitigated risk.
  • Contractor did not fully adhere to HHS procurement guidelines, missing opportunities to capture and consider risk important to program success.
  • Changing requirements and oversight contributed to significant cost growth, schedule delays, and reduced capabilities.
  • Unclear contract oversight responsibilities exacerbated cost growth.
  • Significant contractor performance issues without corrective actions.

So when we hear 

Workshop

Think in what domain, with what value at risk, with what complexity of project, and what business process in which these could possibly be applicable. In fact this goes back to the core of the agile manifesto. And when we hear "pure agile," Scrum Masters produce Scrum Slaves, Mob Programming, "we all want a seat at the table with equal voices, and many other "opinions," remember Moynihan and ask for facts, domain, past performance, experience, and examples of success.

As agile starts to scale to larger domains and the government seeks better ways to develop software beyond the failed processes described above - what parts of this manifesto are applicable outside of a small group of people in the same room with the customer directing the work of the developers?

As my colleague (former NASA Cost Director) reminds our team if you see something that doesn't make sense - follow the money. In the case of ACA and in the case of the Work Shop outcomes above.

Related articles Can Agile Be Integrated with Governance Based Development Processes? Agile Means ... Can Enterprise Agile Be Bottom Up? Agile as a Systems Engineering Paradigm How To Create Confusion About Root Causes Agile and the Federal Government Quote of the Day - Just a Little Process Check Sailing and Agile
Categories: Project Management

Making Decisions

Sat, 09/06/2014 - 23:07

Making Multi-Objective DecisionsAlmost all decision problems involve the simultaneous considerations of different objectives that are many times in conflict.

In the software development world this might be characterized by a customer wanting a set of features to be delivered for a budget on a certain date so those features can be put to work earning back their cost.

Since the list of features is likely to needed to be developed in a specific order with varying costs, the question is what features should be done first and what features down next. 

The traditional response from an agile developer is the define the value of those features and produce them in that order. What is the unit of measure of value. That's rarely stated. But along with the Value is the cost of that value and other attributes of the development process. Risk, resource demand, inter dependencies between other features, inter dependencies between these features and external processes - the externalities of all complex problems.

The formal discipline is this process is called Multi-Criteria Decision Analysis (MCDA). MCDA has the following elements:

  • A goal, objective, or criteria to be achieved
  • A ¬†need to be fulfilled
  • Constraints and requirements associated with and affected by the decision
  • Decision options or alternatives
  • The Environment in which the decision must be made
  • The Experience and background of the decision makers

The methods to solve these types of problems started in the 1950's with Churchman and Ackoff, and were axiomatized by Debreu in 1960, along with Luce and Tukey, Krantz, and Scott.

The principles in these early papers and the continued development of multi-criteria decision making have now moved to nearly every domain where scarce resources, probabilistic outcomes, uncertainty of the impact of the decisions, and value at risk is high enough to ask the question

What will be the outcome of this decision on the future of the processes, cost, technology, environment, or any other external domain?

So when we hear that

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

We have to wonder if these frameworks, investment models, and project management methods have come in contact with the reality of how business works. As Carl saying in a somewhat harsh manner

Extraordinary claims require extraordinary evidence. Carl Sagan

Related articles Positive Deviance 5 Questions That Need Answers for Project Success
Categories: Project Management

Focus on Value is Only ¬Ĺ The Equation

Fri, 09/05/2014 - 16:54

ValueWhenever I hear "we need to focus on value" it tells me that only ¬Ĺ the equation of business ¬†success is understood.

Absolutely value is needed and is the focus of our work efforts. No customer is going to pay for a product or service that doesn't have the needed value. This value is usually in a unit of measure around a "capability" to do something for the that in turn solves a problem, generates revenue, enables another process to function.

Measures of Effectiveness to get the job done. Measures of Performance while getting the job done. The Technical Performance Measures of the underlying hardware, software, people processes that enable the job to get done at the right cost.

But this value is an enabler. The units of measure of the value are defined by the customer, not the provider. The Marketing department of the provider may have suggestions about the value of the product or service, but it is the customer that confirms that value.

In doing the confirmation of Value, the buyer (internal or extermal customer) makes this assessment using a foundational principles of all business decisions...

Microeconomics

Microeconomics is a branch of economics that studies the behavior of individuals and small impacted organizations in making decisions on the allocation of limited resources. Those limited resources to the buyer are:

  • Time - the need for the capability provided by the¬†Value produced by the developer usually has a time frame on it. If that¬†Value could arrive any time, then it is unlikely the¬†Value of the Value is very high.
  • Money - the other limited resource is money. How much does the Value cost?

The time value of money is then used by the buyer to enable another decision making process

ROI = (Value - Cost ) / Cost

So when we hear, we don't need to know the cost, that is we don't need to estimate the cots of producing the value, think again. This can only be true if the delivered value takes place in the presence of unlimited resources. That is we have all the time we need and no one really cares about the cost. That is the principle of microeconomics of business decision making is not in play.

As a final point. Budget is NOT Cost. Setting the budget, only sets the budget. The cost of the work is called Actual Cost and actual cost is generated by exchanging labor and materials for money. So setting the budget is needed. But setting the budget only says what the expected cost might be. If you're given an budget and an expected set of Value outcomes, estimates of the confidence of delivering that Value will be needed. Otherwise your budget is just a number, that will easily be blown before you delivery the needed capabilities on the needed date.

If asked what should our budget be for the expected Value, then solving the ROI or Expected Monetary Value, or Value at Risk needs to take place. In order to do this for a decision about the future ROI, EMV, or VAR, we need to estimate both the Cost and Value - then manage the project that produces the Capabilities that deliver the Value toward both those cost and time variables. And of course those variables are random variables.

When it is stated in an work shop where the participants will learn about

  • Decision making frameworks for project that don't require estimates.
  • Investment models for software project that don't require estimates.
  • Project management (risk management, scope management, process reports) approaches that don't require estimates.

Then those processes are not operating in a governance domain where microeconomics of product developments are in place. Can't say where they are operating, but it's not on this planet of a for profit business. Or those proffering this approach have discovered a secret sauce that gets around the basic principles of all business -

Profit = Revenue - Cost of Goods Sold

The only place I know this principle is not in place, is here in Colorado, just outside of Fairplay, CO, is South Park.

South-park-bowl-and-grill

Here in South Park, the local businessmen have a clever plan to get rich without be subject to microeconomics of making decisions about how to do that.

Screen Shot 2014-09-05 at 9.39.44 AM

Categories: Project Management

Quote of the Day ‚ÄĒ Just a Little Process Check

Fri, 08/29/2014 - 15:12

Everyone is entitled to his own opinion, but not his own facts.‚ÄĒ Daniel Patrick Moynihan

When engaging in exchanges about complex topics like cost, schedule, and technical performance management, I always get a smile when someone says oh that problem can be solved with this simple approach. Or I bet that organization has no motivation what so every to solve the problem. 

Then the next quote is applicable...

For every complex problem there is an answer that is clear, simple, and wrong. ‚ÄĒ H. L. Mencken

Solving complex problems is hard, stating there are simple solutions without having worked on complex problems is easy.

Related articles Complex Problems Require Better Solutions The Three Elements of Project Work and Their Estimates The Power of Misattributed and Misquoted Quotes Is There Such a Thing As Making Decisions Without Knowing the Cost?
Categories: Project Management

Quote of the Day - All Things Project Are Probabilistic

Wed, 08/27/2014 - 16:28

As far as the laws of mathematics refer to reality, they are not certain, as far as they are certain, they do not refer to reality.

‚ÄĒ Albert Einstein Sherwin, Ronald Paul (2014-08-17). In The Tao of Systems Engineering: An Engineer's Survival Guide (pp. 195-197). Ronald Paul Sherwin. Kindle Edition.

When ever you hear that we can't predict the future. Think again. We can always predict the future. The level of confidence of that future is what is in question.

When you hear estimating is guessing. Think again. That person doesn't understand probability and statistics. When you hear we don't need to predict to make decisions, that person has very little at risk from that decision, since making decisions in the absence of knowing the possible loss ignores the principles of microeconomics of everyday life.

When ever you hear we don't need to estimate the outcomes of our decisions. Think again. We don't need to estimate those outcomes only if they are of low enough value that we don't care about the consequences of not knowing to some level of confidence what happens as a result of our decision. We're willing to wright off our loss if we're wrong.

When we hear any conjecture that involves mathematics that does not address the foundation of the mathematical principles of that discussion, remember Einstein, and also remember how to apply that advice in the specific domain and context of the question guided by Deming.

Management is Prediction 

Deming 2

Since management is prediction, knowing how to make predictions using statistical methods to produce a confidence interval about the probabilistic outcomes of those business decisions is part of management. When we want a sit at the table where management decisions are being made, knowing this and being able to add value to the decision process is the price of entry to that room. Otherwise we're labor sitting outside the room waiting for the decisions to be made. 
 

Categories: Project Management

Navigating the Way Home

Wed, 08/27/2014 - 03:10

Manx shearwaterI came across a nice blog post from DelancyPlace about the navigation powers of birds. 

This bird was taken from Wale's to Venice Italy and released and found it's way home in 14 days. 930 miles, over mountains .

To be able to find their way home from an unfamiliar place, birds must carry a figurative map and compass in their brains.

The map tells them where they are, and the compass tells them which direction to fly, even when they are released with no frame of reference to their home loft.

Projects Are Not Birds

As project managers, what's our map and compass? How can we navigate from the start of the project to the end, even though we haven't been on this path before. 

How can we find our way Home?

We have a map. It starts with a Capabilities Based Plan. The CBP states what Done looks like in units of measure meaningful to the decision makers. These units of measure are Measures of Effectiveness and Measures of Performance.

  • Measures of Effectiveness - are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.

  • Measures of Performance -¬†characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

These measures speak to our home and the attributes of the home. The map that gets us ti home is the Integrated Master Plan. This shows the increasing maturity of the deliverables that implement the Measures of Performance and those Performance items that enable the project to produce the needed capabilities that are effectively accomplish the mission or fulfill the business need. 

This looks like a map for the increasing value delivery for an insurance company. The map shows the path or actually paths to home. Home is the ability to generate value from the exchange of money to develop the software.

Project Maturity Flow is the Incremental Delivery of Business Value

Related articles Golden Ratio Managing In The Presence Uncertainty Impact Mapping and Integrated Master Planning We Can Know the Business Value of What We Build All Project Work is Probabilistic Work 5 Questions That Need Answers for Project Success
Categories: Project Management

Quote of the Day

Tue, 08/26/2014 - 13:16

"All the mathematical sciences are founded on relations between physical laws and laws of numbers, so that the aim of exact science is to reduce the problems of nature to the determination of quantities by operations with numbers."
‚ÄĒ James Clerk Maxwell, On Faraday's Lines of Force, 1856

Categories: Project Management

Management is Prediction - W. Edwards Deming

Tue, 08/26/2014 - 01:44

DemingThis statement Management is Prediction is the basis of the microeconomics of writing software for money, someone else's money. 

Along with the quote of Daniel Boorstin's,¬†The greatest¬†obstacle to discovery is not ignorance ‚Äď it is the illusion of knowledge. Boorstin was the Librarian of Congress. One of his other quotes was once the subtitle of this blog¬†I Write to Discover What I Think.

And here's what I think about the predictive nature of managing projects. If we don't know how to estimate the impacts of our decisions on the future outcomes of those decisions, we have the illusion of knowledge, when in fact we have no knowledge.

There is a popular myth, that estimating the future outcomes of our present day decisions is somehow voodoo, guessing, making things up, and having our management treat them as commitments. It's clear we didn't pay attention in the probability and statistics class. Or worse yet, we have intentionally ignored what we did learn in that probability and statistics class. Thinking naively or with intent ignoring the probabilistic nature of all project work.

All variables in project work are random variables. These variables are almost always coupled to each other in some way, usually a non-linear way. Fix one variable, the other two are free to be variable. Fix two variables, the third variable is free. Fix all three, they still vary. This is the primary reason margin is needed for project to have a credible chance of showing up on time, on budget, and on value. These variances are Irreducible, meaning they will vary no matter what you do. Fixing Budget, only fixes the amount of money you've allocated to the project. It doesn't fix the cost to produce the value from the project, nor the time to produce that value.

Slide1

So Why Do We Estimate?

When ever possible we should use evidence in making decisions about project variables. Observing the behaviour of the variables in an attempt to see what they are doing, where they are going, what the next outcome might be. 

This is the basis of the OODA Loop. Boyd was an Air Force fighter pilot, and like Jeff Sutherland of agile fame, understood that emerging situations are the norm in the skies of Vietnam, just like they are on projects.

OODA ClipThe OODA loop is often popularized as four elements going around in a circle. The picture is the only diagram Boyd ever drew. Boyd's OODA Loop describes the details. The title of the chart above comes from one of our briefings for Managing in the Presence of Uncertainty. But the domain OODA is applicable is not restricted to DOD acquisition, but is applicable in any domain where money, time, and performance are at risk.

Just to push a little harder, when you hear about Clausewitz and Tzu from agile coders, remember Boyd's comments when he spoke in public

‚ÄúDon‚Äôt be a member of Clausewitz‚Äôs school because a lot has happened since 1832,‚ÄĚ he would warn his audiences, ‚Äúand don‚Äôt be a member of Sun Tzu‚Äôs school because an awful lot has happened since 400 BC.‚ÄĚ

So just like those reference to 1968 reference to the Software Crisis - a lot has happened since then.

So Here's a Simple Fact

Also often ignored by some wanting us to learn to decide without knowing the impacts of those decisions.

People learn better when they predict

Making an estimate about the future ‚ÄĒ predicting¬†on outcome or impact ‚ÄĒ forces us to think ahead about those very outcomes. Making an estimate causes us to examine more deeply the system we are observing and our engagement with that system and our reactions to the system. It causes us to question our understanding of the system as it is now ‚ÄĒ in ¬†its current state ‚ÄĒ and what we would like it to be in its future state. As well, by making estimating about future outcomes, we can learn more about our understanding of the management beliefs we hold as we examine the results of our predictions.

So like Deming tells us ...

Management is Prediction

Not making prediction's about the impact of our decisions, the processes affected by those decisions, like - cost, schedule, and technical performance - shown in the three legged picture above, ignores the principles of Deming. And when we do that, ...

... we're not managing how we spend other peoples money.

The only way this notion can't be called bad management is if the amount of money at risk is low enough that those providing the money don't care if we waste it or not.

Related articles Making Estimates For Your Project Require Discipline, Skill, and Experience Why We Must Learn to Estimate The OODA Loop - Insight into Strategic Thinking An Agile Estimating Story Averages Without Variances are Meaningless - Or Worse Misleading Four Critical Elements of Project Success The Value of Information What does a "broken OODA loop" look like? How To Create Confusion About Root Causes
Categories: Project Management

What I Don't Know Can Actually Hurt Me

Fri, 08/22/2014 - 19:23

Ostrich Head in SandThe notion of not knowing the impact of decisions, choices, approaches is like putting your head in the sand because you don't like the answer or don't what to know the answer.

In our domain there are three common root causes for program difficulties when the program overruns it's budget, shows up late, or the delivered product doesn't work as required

  1. They couldn't know - the source the problem was in fact unknowable.
  2. They didn't know - the source of the problem was knowable, but the effort to discover it was done.
  3. They dodn't want to know - the source of the problem was there, but if it was made visible the project would be canceled or not started

When I read about decision making processes like ...

Screen Shot 2014-08-22 at 12.07.24 PM

I'm struck by the 3rd statement. Knowing something about the cost of a decision, the outcome of an investment, the risks, scope impact, progress reporting of future values requires you make estimates. Since all project variables are random variables that interact in random ways - technically non-stationary stochastic processes - knowing about the impacts from deciding anything using these variables means estimating the three core variables of all projects, shown below.

When I hear the suggestion that decisions can be made in the absence of those estimates, think of the Ostrich, ask the following:

  • Can I decide about some future outcome without estimating the impact of that outcome?
  • If I'm going to invest - spend money - can I do the ROI calculation in the absence of the estimate of the cost or the value - since neither of those are known on day one?
  • Risk - by it's very definition - is an uncertainty. These uncertainty are probabilistic outcomes of future events. Estimates are needed.

If there ways to decide these things without estimates, let's hear them. Each of the three variables and each of their drivers is a random variable whose value is not know in the present, but can only be knowing with an estimate of it's future possible values.

Screen Shot 2014-08-22 at 12.11.42 PM

Related articles Resources for Moving Beyond the "Estimating Fallacy" Making Estimates For Your Project Require Discipline, Skill, and Experience Four Critical Elements of Project Success First Comes Theory, Then Comes Practice How to Deal With Complexity In Software Projects? Statistical Process Control The Basis of All Modern Control Systems Let's Stop Guessing and Learn How to Estimate The Value of Information Why is Statistical Thinking Hard?
Categories: Project Management

No News is Bad News - Feedback Must Create Steering Signal from Plan †

Wed, 08/20/2014 - 22:41

Screen Shot 2014-08-20 at 12.39.03 PMProject Manager: How's the project progressing to plan? 

Developers: We're spending money, consuming resources, producing outputs that the customer likes. 

Project Manager: I was more interested in what's our performance against our planned spend, planned resource consumption, and planned outputs of value to the customer? 

Developers: What do you mean, we didn't estimate any of that, we're managing this project with #NoEstimates. You know that new alternative to estimates for making decisions in software development. That is ways to make decisions with "No Estimates." of the impacts on the future of those estimates or of our work on the future cost, schedule, or technical performance. You know where we can use Decision making frameworks for projects that do not require estimates, or apply Investment models for software projects that do not require estimates, and have our project management methods for risk management, scope management, progress reporting, not require any of those annoying estimates. 'Cause we kinda suck at them anyway, so we just decided instead of learning how to estimate, we'll just not estimate and get back to coding.

Project Manager: Oh, you mean that approach of managing other peoples money that violates the principles of software microeconomics with Open Loop Control - where our organization can make business decisions on the allocation of our limited resources, without examining how those decisions effect the supply and demand of our resources. You do know about those resources? Like money, people, and time?

Developers: Yea, we don't need any that mumbo jumbo microeconomics that we all learned in school, since we didn't pay attention in that boring the statistics and probability class that tried to teach us that all variables on a project are actually random variables and we should to know something about their behaviour in the future if we're going have a hope in hell of ever managing this project in the presence of uncertainty about those values.

Project Manager: What's that smell? Maybe we'd better start rearranging the deck chairs on our ship here real soon, cause I smell an Iceberg getting closer.

No project can be managed to successful closure in the absence of steering targets defined at periodic intervals for the expenditure of cost, schedule, and technical performance. Knowing what those steering targets should be requires estimating their values, then measures the actual values to develop the needed steering signal - the variance between plan and actual.

The only way out of the need to estimate those intermediate steering targets is to straight line the budget, schedule, and needed technical performance - from start to end, then measure the actual performance. 

Like the intended route of the Titanic, our project does not proceed in a straight line, so that idea is a non-starter. And like the Titanic, our project cannot confuse the intended speed with the actual speed, just like we can't confuse the budget - the total planned crossing time - with the actual cost - the actual total crossing time.

Titanic-Route

Without those pesky intermediate targets to steer toward - those targets created by estimating the needed cost, needed scheduled arrival date, and, needed capabilities on the needed date for the needed cost. We're managing the project Open Loop, driving in a straight line. Never knowing what will pop up in front of our path. 

Say good bye to Kate Leonardo, you're gonna get wet.

† Full attribution for the inspiration for this post comes from the very useful blog by Gene Hughson

Related articles Staying on Plan Means Closed Loop Control How Not To Make Decisions Using Bad Estimates Control Systems - Their Misuse and Abuse More Than Target Needed To Steer Toward Project Success Why Project Management is a Control System
Categories: Project Management

Systems Thinking and Capabilities Based Planning

Tue, 08/19/2014 - 04:23

The term Systems Thinking is many times used in vague and unspecified ways to mean think about the system and all will emerge in a way needed to produce value. 

Systems Thinking is a term toosed around many times with little regard for what it actually means and its relationship to Systems Engineering and Engineered Systems.

But systems thinking is much more than that. Systems thinking provides a rigorous way of integrating people, purpose, process and performance and: †

  • relating systems to their environment.
  • understanding complex problem situations
  • maximising the outcomes achieved.¬†
  • avoiding or minimising the impact of¬†unintended consequences.
  • aligning teams, disciplines, specialisms and¬†interest groups.
  • managing uncertainty, risk and opportunity.

†  "How Systems Thinking Contributes to Systems Engineering," INCOSEUK, Z7, Issue 1.0, March 2010.

Related articles A Breathtaking Paper Positive Deviance
Categories: Project Management

Why Is It Hard To Manage Projects?

Mon, 08/18/2014 - 05:36

In the absence of a control system that provides feedback to the progress to plan, the project is just wandering around looking for what Done looks like. The notion of emergent requirements is fine. The notion of emergent capabilities is not.

If we don't know what capabilities are needed to fulfill the business plan or fulfill the mission need, then we're on a Death March project. We don't know what value is being produced, when we will be done, or how much this will cost when we're done.

This is the role of the project control system. Without a control system there is no way to use feedback to steer the project toward success.

Control systems from Glen Alleman So when we hear we can make decisions wihout estimating the impact of those decisions on the furture outcomes of the project, we'll know to call BS. First not knowing this impact on the decision making process violates the principle of Microeconomics and second there is no way to close the loop to generate a variance signal needed to steer the project to success. Related articles Staying on Plan Means Closed Loop Control Concept of Operations First, then Capabilities, then Requirements Delivering Needed Capabilities What Do We Mean When We Say "Agile Community?" More Than Target Needed To Steer Toward Project Success Getting to done!
Categories: Project Management

The Purpose Of Guiding Principles in Project Management

Thu, 08/14/2014 - 16:02

Five principles

A Guiding Principle defines the key criteria for making decisions about the application of a project's Practices and Processes. The Principles provide the project with the foundation to test the practices and processes in pursuit of the project's goals in the most timely and cost-effective way while still meeting essential requirements of business outcomes or mission accomplishment.

In the absence of Principles, the Practices and Processes - while possible the rights one - have no way of being tested to assure they are producing actionable information for the management of the project. 

The common lament of we could be spending time and effort doing something more useful, ignores the fact that those  useful things need to be guided by a higher structure - a holistic structure - of exchanging cost for value. The questions should be are the practices and processes we are applying to this project the proper ones to maximize the efficacy of our funding?

These five principles are the foundation of project success. Success means - in the simplist terms - On Time, On Cost, On Value. Time and Cost are easily defined, Value needs another layer for it to be connected with Time and Budget.

What is Strategy

One approach for Value to to connect the outcomes of the project with the¬†Strategy for the business or the mission.¬†Strategy is creating fit among a company‚Äôs activities. The success of a strategy depends on doing many things well ‚Äď not just a few. The things that are done well must operate within a close nit system. If there is no fit among the activities - in this post, the project management activities - there is no distinctive strategy and little to sustain the project management practices and processes. Project Management then reverts to the simpler task of overseeing independent functions. When this occurs operational effectiveness determines the relative performance of the project management activities and the results of the project itself.¬†

Improving operational effectiveness is a necessary part of management, but it is not strategy. In confusing the two, managers will be unintentionally backed into a way of thinking about competition that drives the business support processes (IT) away from the strategic support and toward the tactical improvement of operational effectiveness.

The concept of fit among functions is one of the oldest ideas in strategy. Gradually, it has been supplanted with new concepts of core competencies, critical resources and key success factors. Fit is far more critical to the success of the project management System. Strategic fit among the project management Practices and Processes and the business processes in which the project is deployed is fundamental not only to competitive advantage but also to the sustainability of that advantage. 

This is the fundation of success for Project Based Organizations

The mechnism for creating this Fit is the Programmatic Architecture of the project. This architecture is the same term used for technical architecture. It is the form of the project, in the same way it is the form of the product or service.

The Five Principles That Establish Programmatic Architecture

These Five Principles and their Practices are...

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman Related articles What Is Strategy? Elements of Project Success Why Project Management is a Control System Creating Effective Mission Statements That Have Meaning and Function Performance Based Management Principles First, Then Practice Moving EVM from Reporting and Compliance to Managing for Success Project Maxims How To Make Decisions
Categories: Project Management

Seven Principles of Agile Software Development in the US DOD

Wed, 08/13/2014 - 23:36

The Software Engineering Institute is a FFRDC (Federally Funded Research and Development Center). An FFRDC, IDA, is a client.

SEI is focused on helping the DOD improve the development of software.

Here are Pod Casts of the Principles of Agile Development of software in the DOD

  • First Principle¬†- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.‚ÄĚ
  • Second Principle - Welcome changing requirements, even late in development
  • Third Principle - Delivering working software frequently‚ÄĚ
  • Fourth Principle - Business people and developers must work together daily throughout the project.
  • Fifth Principle - Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  • Sixth Principle - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  • Seventh Principle - Working software is the primary measure of progress
Related articles Is Your Organization Ready for Agile? Three Kinds of Uncertainty About the Estimated Cost and Schedule Can Enterprise Agile Be Bottom Up? What Do We Mean When We Say "Agile Community?" Studies, Science, Cybersecurity & Saddam: $888.8M to IDA for its 3 US FFRDCs from 2014-2018.
Categories: Project Management

The Ruckus About DDSTOP Post

Wed, 08/13/2014 - 18:03

OpinionAwhile back I posted about Don't Do Stupid Things On Purpose (DDSTOP). This caused some comments about this being a very Theory-X management approach. The notion of Don't Do Stupid Things on Purpose comes from observinig people DSTOP with other peoples money.

Many might say, people have to experiment, try thing out, test the waters. Yes this is true, but who pays for that testing, trying, experimenting? Is there budget for that in the project plan? May be that this is actually an experimental project and the whole point of the project is to do stupid things on purpose to see what happens. 

I wonder if the experimental work being paid for by the customer were worded like that if it would sound so clever?

Here's some clarity and a few examples of DSTOP in recent years.

  • Install CA's Clarity (a very expensive project management and project accounting system).
    • Apply Earned Value to a large ($250M) Enterprise IT project. Project gets in trouble, we come on board to perform¬†triage and discover that the Program Management Office has been copying ACWP - the Actual Cost of Work Performed - to BCWP - the Budgeted Cost of Work Performed - the Earned Value - then reporting to senior management that everything is going fine.
    • Instead of actually measuring physical percent complete to compute BCWP, they simplied copies the cost of the budgeted work, hiding the actual process
    • That's DSTOP
  • Install TTPro as a defect tracking and help desk ticketing system,
    • Communicate verbally most of the defect repairs dome in development.
    • Lose the traceability between the defect and the fix, so the QA staff can't trace the defects back to their rest coverage suite
    • That's DSTOP
  • Plan the development of several 100 million $ of flight avioncis upgrades for an aircraft that has been upgraded in the past.
    • Build the Integrated Master Schedule around the past performance activities - good idea
    • Resource load the IMS from past performance - good idea
    • Discover that the cost and schedule don't fit inside the stated needs of the customer, so¬†dial the work durations and assigned labor loads to fit the¬†price to win for the RFP
    • Get awarded the control, go over budget, and show up late after 12 months of work, get contract canceled
    • That's DSTOP

So is it Theory X to ask those working on the project and managing the project to stop and think about what they are doing, what decisions are being made - and assess the impact of those decisions? Or should those entrusted with the customers money just go exploring, trying out ideas with the hope that something innovative will come out of it?

When we're assumed to be the stewards of other people's money, they should expect us to behave as those stewards. This means we make decision about the use of that time and treasure is ways that are informed by our experience, skills, and governance model. Doing otherwise means we're not the right people to be spending our customers money, or our customer has a lot of money to spend on us to become the right people they should have hired to spend their money.

Related articles In Earned Value, Money Spent is Not a Measure of Progress! What Do We Mean When We Say "Agile Community?"
Categories: Project Management

Staying on Plan Means Closed Loop Control

Tue, 08/12/2014 - 00:19

Screen Shot 2014-08-11 at 5.03.33 PMFor most projects showing up on or near the planned need date, at or near the planned cost, and more or less with the planned capabilities is a good measure of success. Delivering capabilities late and over budget is usually not acceptable to those paying for our work.

So how do we do this? Simple actually.

We start with a Plan. Here's the approach to Planning and the resulting Plan.

Planning constantly peers into the future for indications as to where a solution may emerge. A Plan is a complex situation, adapting to an emerging solution. 
- Mike Dwyer, Big Visible

The Plan tells us when we need the capabilities to produce the needed business value or accomplish the mission. The Plan is a strategy. This strategy involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions. The strategy describes how the ends (goals) will be achieved by the means (resources) in units of measure meanigful to the decision makers.

Strategy creates fit among a firms activities. For Enterprise IT, this fit is defined by the relationships between the needed capabilities delivered by the project. The success of a strategy depends on doing many things well ‚ÄĒ not just a few.

The things that are done well must operate within a close nit system. If there is no fit among the activities, there is no distinctive strategy and little to sustain the strategic deployment process. Management then reverts to the simpler task of overseeing independent functions.

When this occurs operational effectiveness determines the relative performance of the organization. ["What is Strategy,‚ÄĚ M. E. Porter, Harvard Business Review, Volume 74, Number 6, pp. 61‚Äď78.]

As successful Plan describes the order of delivery of value in exchange for cost, the inter-dependencies between these value producing items, and the synergistic outcomes from these value producing items working together to meet the strategy.

With the Plan in hand, we can ask and answer the following questions:

  • Do we know what Done looks like in units of measure meaningful to the decision makers?
  • Do we have a strategy for reaching done, on or near the need date, at or near the budget?
  • Do we have the resources we need to execute that strategy?
  • Do we know what impediments we'll encounter along the way and how we're going to handle them?
  • Do we have some means of measuring our progress along the way to provides the confidence we'll reach done when we expect to?¬†

This Post Answers the Last Question

The example below is from our cycling group. The principles are the same for projects. We have a desired outcome in terms of date, cost, and technical performance. These desired outcomes have some end goal. A budget, a go live date, a set of features or capabilities needed to fulfill the business case. 

Along the way we need to take corrective actions when we see we are falling behind. 

How did we know we were falling behind? Because we have a desired performance at points along the way, that we compare our actual performance to. The difference between our actual performance and the desired performance, creates an "error signal" we can use to make adjustments.

Out thermostat does this, our speed control on our car does this, the Close Loop Control systems used for managing our project does this. So replaces the cycling example with writing software for money. The Peleton for the desired performance of our work. In the presentation below, ignore the guy in the Yellow Jersey at the end. Turns out he's a Dopper and an all around bad person to his fellow riders and fans.

The simple problem of schedule performance indices from Glen Alleman So let's look at a project example using the analogy of our cycling group, ignoring Lance.
  • We have a goal of riding a distance in a specific time. This can be a training ride, a century, or a Grand Fondo (timed distance for record).
  • We have instruments on the bike. Strava on the smart phone. Gamin on the bars. Both keeping track of instantaneous speed, time moving, total time. As well an average time over the distance.
  • We know, because we've done this route A 100 times before, or we know because we looked at the coure map, or we know because we have talked about the planned distance for the day - about how fats we need to ride - on average - to get back to the drive on a planned time.
  • Say we're out for our Saturday ride, which is usually a 50 to 65 mile loop from the driveway in Niwot Colorado to Carter Lake south of Fort Collins.
  • As a group we agree our average pace will be 20 MPH. Everyone has some way of measuring their average and instantaneous speed.
  • Over the course, it's never flat, some climbs and descents, change the flat land speed, but the average needs to stay at 20 MPH.¬†
  • When one or more¬†drop off the back, I'm usually one of those, we know what are average is. And instinctively we know how much faster we need to ride to catch up -¬†pick up the pace.
  • But if we were actual racers riding solo -¬†time trial or Triathlon, we'd look at our Garmin to see if we're going fast enough to¬†get back on pace, and come in under our target time.

This example can be related to a project. 

  • We have a target for the end ‚ÄĒ a target set of capabilities, with a need date, and a target budget
  • We have targets for all the intermediary points along the way ‚ÄĒ capabilities over time, budget over time.
  • We know our¬†pace ‚ÄĒ how fast to we have to go, how much cost can we absorb, to make our goal of delivering the needed capabilities on the needed date, for the needed budget.
  • We know the gap between our¬†pace and our¬†needed pace¬†to stay on track ‚ÄĒ with an intermediate desired performance, budget, number of features delivered, stated capabilities ready to be ¬†used, and the actual measures of these, we can develop a¬†variance that is used to product an error signal that is used to steer to the project. This is the feedback loop. The closed loop control system we need to keep the project on plan.
  • From that¬†variance we know how much faster we need to go to arrive on time.

This is Close Loop Control

  • Have a target for the end and we have intermediate targets along the way. These intermediate targets are the feedback points we use to assess progress to date
  • Measure the actual value of whatever variables we need to provide visibility to the project's performance. This can be cost, schedule, performance. But it can be other attributes of the project. Customer acceptance. Market place feedback. Incremental¬†savings.
  • Determine the variance between the plan and the actual.
  • Take corrective action to close the gap to get back on target ¬†or get within the variance tolerance.
  • Repeat until project ends.

You're cruise control does this about every 10 milliseconds. You Nest thermostat does this slower, but still less than a minute. To know how often you need to sample your progress against plan, answer this question

How long are you willing to wait before you find out you're late? Sample at ¬Ĺ that time.

This is called the Nyquist Rate, one of the starting point for all the process control software I wrote in my youner days for flying and swimming machines. But it's a good question to ask on all projects as well.

Related articles Is There Such a Thing As Making Decisions Without Knowing the Cost? Time to Revisit The Risk Discussion Can Enterprise Agile Be Bottom Up? Process Improvement In A Complex World Why Project Management is a Control System If you want to pretent you're a Pro, then starting acting like one Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success More Than Target Needed To Steer Toward Project Success
Categories: Project Management

Quote of the Day

Sun, 08/10/2014 - 18:27

"You cannot have an execution culture without robust dialog - one that brings reality to the surface through openness, candor, and informality.
This is called "truth over harmony"

in Execution: The Discipline of Getting Things Done, Larry Bossidy and Ram Charan

Related articles Practices without Principles Does Not Scale The Need for Strategy How to Manage in the Presence of Uncertainty
Categories: Project Management

More Than Target Needed To Steer Toward Project Success

Sat, 08/09/2014 - 15:49

There is a suggestion that only the final target of a project's performance is needed to steer toward success. This target can be budget, a finish date, the number of stories or story points in an agile software project. With the target and the measure of performance to date, collected from the measures at each sample point, there is still a missing piece needed to guide the project.

With the target and the samples, no error signal is available to make intermediate corrections to arrive on target. With the target alone, any variances in cost, schedule, or techncial performance can only be discovered when the project arrives at the end. With the target alone, this is an Open Loop control system.

Control systems from Glen Alleman Pages 27 and 28 show the difference between Open Loop control and Closed Loop control of a notional software development project using stories as the unit of measure. In the figure below (page 27), the cummulative performance of stories is collected from the individual performance of stories over the projects duration. The target stories -  or budget, or some other measure - is the final target. But along the way, there is no measure of are we going to make it at this rate?  An Open Loop Control System
  • Is a non-feedback system, where the output ‚Äď the desired state ‚Äď has no influence or effect on the control action of the input signal ‚ÄĒ the measures of performance are just measures. They are not compared to what the performance¬†should be at that point in time.
  • The output ‚Äď the desired state‚Äď is neither measured nor ‚Äúfed back‚ÄĚ for comparison with the input ‚ÄĒ there is not an intermediate target goal to measure the actual performance against. Over budget, late, missing capabilities are only discovered at the end.
  • Is expected to faithfully follow its input command or set point regardless of the final result ‚ÄĒ the planned work can be¬†sliced into small chunks of equal size - this is a huge assumptions by the way - but the execution of this work must also faithfully follow the planned productivity. (See assumptions below).
  • Has no knowledge of the output condition ‚Äď the difference between desired state and actual state ‚Äď so cannot self-correct any errors it could make when the preset value drifts, even if this results in large deviations from the preset value ‚ÄĒ the final target is present but the compliance with that target along the way is missing, since there is no intermediate target to steer toward for each period of assessment - only the final.
Screen Shot 2014-08-09 at 7.46.27 AM There are two very simplifying assumptions made in the slicing approach sugegsted to solve the control of projects: 
  • The needed performance in terms of stories or any other measure of performance are linear and of the same size - this requires decompsong the¬†planned¬†work for each period to nearly identical sizes, work efforts, and outcomes.
  • The productivity of the work performed is also linear and unvarying - this require zero defects, zero variance in the work effort, and sustained productivity at the desired performance level.
Fulfilling these assumptions before the project starts requires effort and the assumptions about the homogeneity of the planned production, the homogeneity of the work effort, and the homogeneity of any defects, rework, or changes in plan would require near Perfect planning and management of the project. Instead, the reality of all project work is the planned effort, duration, outcomes, dependencies, and cost are random variables. This is the nature of the non-stationary stochastic processes that drive project work. Nothing will turn out as planned during to uncertainty. There are two types of uncertainty found in project work:
  • Irreducible Uncertainty - this is the¬†noise of the project. Random fluctuations on productivity, technical performance, efficiency, effectiveness, risk. These cannot be reduced. They are Aleatory Uncertainties.
  • Reducible Uncertainty - these are¬†event based uncertainties that have a probability of occurring, have a probability of the consequences, and have a residual probability that when fixed will come back back again.

Irreducible Uncertainty can only be handled with Margin. Cost margin, schedule margin, technical margin. This is the type of margin you use when you drive to work. The GPS Navigation system says it 23 ninutes to the office. It's NEVER 23 minutes to the office. Something always interferes with our progress.

Reducible Uncertainty is handled in two way. Spending money to buydown the risk that results from this uncertainty. Management Reserve (budget reserve and schedule contingency) to be used whenm soemthnig goes wrong to pay for the fix when the uncertainty turns into reality.

The next figure (page 28) shows how to manage in the presence of these  uncertainties, by measuring actual performance against the desired performance at each step along the way.

Screen Shot 2014-08-09 at 8.03.15 AM

In this figure, we measure at each assessment point the progress of the project against the desired progress - the planned progress, the needed progress. This planned, desired, or needed progress is developed by looking at the future effort, duration, risk, uncertainty - the stochastic processes that drive the project - and determining what should be the progress at this point in time to reach our target on or before the need date, at or below the needed cost, and with the needed confidence that the technical capabilities can be delivered along the way?  This is closed loop control.

The planned performance, the needed performance, the desired performance is developed early in the project. Maybe on day one, more likely after actual performance has been assessed to calibrate future performance. This is called Reference Class Forecasting. With this information estimates of the needed performance can then be used to establish steering targets along the way to completing the project. These intermediate references - or steering - points provide feedback along the way toward the goal. They provide the error signal needed to keep the project on track. They are the basis of Closed Loop control. 

In the US, many highways have rumble strips cut into the asphalt to signal that you are nearing the edge of the road on the right. They make a loud noise that tells you - hey get back in the lane, otherwise you're going to end up in the ditch.

This is the purpose of the intermediate steering targets for the project. When the variance between planned and actual exceeds a defined threshold, this says hey, you're not going to make it to the end on time, on budget, or with your needed capabilities if you keep going like this.

Ditch 03[1]

Kent Beck's quote is...

Optimism is the disease of software development. Feedback is the cure.

 

This feedback must have a reference to compare against if it is to be of any value in steering the project to a successful completion. Knowing it's going to be late, over budget, and doesn't work when we arrive at late, over budget, and not working is of little help to the passengers of the project.

Related articles Indicators of project performance provide us with "Steering Inputs" Seven Immutable Activities of Project Success Why Project Management is a Control System The Use and Misuse of Little's Law and Central Limit Theorem in Agile Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Slicing Work Into Small Pieces How To Assure Your Project Will Fail Control Systems - Their Misuse and Abuse Getting to done!
Categories: Project Management

Quote of the Day

Fri, 08/08/2014 - 22:31

Strategy without tactics is the slowest route to victory
Tactics without strategy is the noise before defeat.

‚ÄĒ Sun Tzu

Every time you hear about some conjectured great new idea on how to solve a vexing problem, ask what's the actual problem to be solved, what's the root cause of that problem, what domain is this problem found in and what domain is this problem already solved in, and finally ask what's your strategy for assuring that your solution will actually result in a solution that doesn't break something else, violate a business principle, and create an obligation that you didn't think of because you were too busy admiring your cleaver idea?

 

Categories: Project Management