Herding Cats

What Do Systems Engineers Do?

The role of Systems Engineering says what its name says - "engineering of systems." SE is found on most every project outside of IT projects. SE provides the "glue" that integrates all the parts of the project and ensures that theser parts all work together in ways that individual engineering and project management can't.

Here's an introductory course on Systems Engineering from NASA. Each of the modules has soemting to say about projects and systems engineering in general. While the examples are of spacecraft, the principles are applicable to nearly every project.

A Bit of Road Warrior Humor

Planning a trip outside the US (OCONUS) and using US State Department Per Diem rate tables for SOW costing. Hotels, meals, car rental... uh guess there are no hotels. Don't worry that's not my destination.

Quote of the Day

“It appears incontrovertible that understanding failure plays a key role in error-free design of all kinds, and that indeed all successful design is the proper and complete anticipation of what can go wrong.”

Henry Petroski Design Paradigms Case Histories of Error and Judgment in Engineering

Tom Gilb's Work on Agile Project Management

John Goodpasture left a link to the Mary Popendieck Essay, that needs a response. A positive response and I'll try to connect his activities with our Deliverables Based Planning^® This is straight forward:

1. Control projects by the "critical few" - these are defined in the Integrated Master Plan or the System Capabilities. For example for Hubble Space Telescope:
   • Do not harm to the STS
   • Replace the widefield camera that had failed
   • Connect the umbilical to the batteries
   • State the needed capabilities in operational terms - this is call the Concept of Operations (ConOps)
2. Make sure these are business results, not technical results
   • This is context sensitive, for a business system this is obvious
   • For a space craft guidance and navigation system, there is a technical result
   • Define the value in units of measure meaningful to the decision makers
3. Give developers freedom to find out how to deliver the results
   • Define the work packages needed to produce the deliverables.
   • Plan the work packages and put them on baseline
   • The tasks inside the work packages are under the "management" of those working the Work Packages
4. Estimate the impacts of your designs on your quantified goals
   • Define the Technical Performance Measures, Measures of Effectiveness, and Measures of Performance for each deliverable
   • Define the connective - coupling and cohesion between these deliverables
5. Select designs with the best value impacts for their costs, do them first
   • Using the Measures of Effectiveness and Measurement of Performance connect them to the Budgeted Cost of Work Scheduled (BCWS) and to the monetized business case for the deliverables.
6. Decompose the workflow into weekly (or 2% of budget) time boxes
   • Answer the question how long are you willing to wait before you find out you're late?
   • Produce a measure of physical percent complete at ½ that distance in time of less.
7. Change desgins based on quantified value and cost experience of implementation
   • Past performance is almost always a predictor of future performance
   • Use the MoE and MoP to make this decision
8. Change requirements on quantified value and cost experience, new inputs
   • Same as above
9. Involve the stakeholders, every week, in setting quantified value goals
   • If stakeholder are available this is good
   • If not, the some form of Technical Interchange Meeting (TIM) must take place periodically
10. Involve the stakeholder, every week, in actually using value increments
    • This is the basis of Integrated Master Planning
    • Use MoE and MoP for each increment of maturity

Predictive Approach As The Foil For Agile?

It is common in the Agile community of voices to compare Agile Software Development with something else to sell it's benefits. Something the Agile audience can see as undesirable. Some phrase  those looking for a reason to move to Agile that tehy can get behind. This appoach is simple, easy, and of course wrong.

The first choice of the something is "waterfall." Waterfall is a code word for the linear design-code-test with little or no feedback. And that approach to project management is of course is simply Bad Project Management, really bad Project Management. The style of development that is not even used in the US Government Defense systems.

The next comparison is the "predictive approach." This is defined by one Agile thought leader as...

... predictive, shapes the definition of Scope, control of the Project Schedule and Cost, and management of software development process based on roots in scientific management, plan driven management, and manufacturing.

No source for this definition is given, so I'll take the liberty of tossing out the last word, the manufacturing piece, since by definition a project is a temporary endeavor and manufacturing is operations.

But le't use a simple approach in the rhetoric class. Does the inverse of this statement make sense to anyone? That is can we all agree that the invserse is truely the opposite?

I like all dog with brown coats. The inverse; I don't like dogs that don't have brown coats.

If not then the first sentence - the non-inverse - is nonsense as well. 

So if Agile, is the alternative to Predictive,

Do we actually seek to NOT have a process that can predict the cost and schedule of the project?

Do we seek a method that can NOT define the overall Scope of the project?

Are we really seeking a software development method that does NOT have control over cost, schedule, and the scope?

Another concept used is the Winston Royce paper in 1970 showing the "waterfall," approach. Common and used in the materials I'm referencing is the clip from the first page of the paper. The final diagrams shows a fully connected - that is all boxes are connected with each other - diagram with feedback from all work to all work. This is simply bad writing and simple misrepresentation of the facts.

Having worked in the same building (TRW O6) are both Royce's the "waterfall" paper was - and still is - an indictment of the problems introduced when the feedback loops are too long.

Is this the intellectually sound approach to selling agile? I hope not.

This approach is of course nonsense. Agile provides control over scope, actually strict control over scope. Scope is controlled through adherence to the process of the Planning Game or other control mechanisms of how features are added, deleted, changed for the project. This is a method with rules, processes, steps, measurable outcomes, process flows. A method based on an external set of activities for guiding the users through the processes to a desired outcome. Gee that sounds like a process developed from theory and put into practice, just like other processes in the scientific method domain do.

This false comparison of the alternatives to agile with Taylor's 19^th century manufacturing method does a disservice to both agile and the traditional methods. It's one of the approaches that has lost it's appeal once it was realized that agile is a highly disciplined, structured, step by step process, complete with process flow diagrams, defined inputs and defined outputs, and tangible measures of progress to PLAN.

Yes, there is a PLAN. Agile is PLAN based. There's even and entire book dedicated to planing in the agile context. Much of the content of that book is similar to the planning processes found in the US DoD for cost estimating and Integrated Master Planning. That fact that Bad Project management is used in some IT domains have nothing to do with the agile and traditional processes sharing many attributes.

All PLANs must be flexible, emerging, fluid, but once the PLAN is set for the iteration, for the rolling wave, for the work packages, for any duration that can be envisioned to have a level of confidence suitable for the recognized risk, it is executed according to PLAN. See the trend here. Agile has PLANs. All projects are plan based otherwise they would fail.

The next nonsensical approach is to suggest that cost and schedule are somehow anti-agile.

Not credible project in which someone else's money is being spent can fail to answer three simple questions:

• When is this project going to be done?
• How much is it going to cost when we're done?
• What am I going to get for my money, at the time you say you're done?

The Fallacy of Planning

Jerry Bishop's blog post titled The Fallacy of Planning raises an interesting question. Jerry mentions cognitive bias as one source of the problem. But this bias only exists in those who fail to recognize they are biased.

But a much deeper problem exists...

The estimates prepared by cost estimators are crucially dependent on technical and programmatic assumptions over which they have little or no say . There are some gray areas; cost estimators should recognize - and provide corrections for in their estimates - some type of unrealistic program assumptions and some likely execution problems. But, without trying to fix the boundaries of these exceptions, it is clear that they are exceptions - cost estimators generally are not equipped to do engineering analyses of proposed programs or to assess the capabilities of potential contractors (McNicol, 2005, p. 19)

The examples Jerry provides of innumeracy are not the source of the problem in our domain. It may be common in IT though.

So how can IT estimimates be improved? First is to move toward what is done in our domain - have professional estimators. This is still a problem for large weapons systems. But without professional estimators or a professional grade estimating process, there is little or no help in improving the credibility of cost estimates.

Here's some background for addressing Jerry's issue - Eliminating Bias Through Reference Class Forecasting and Good Governance, Bent Flyvberg,

Mary Popendieck Essay

Mary has a new essay titled Don't Separate Design from Development. It's one of those "looking back, to see forward" style of essays. I suspect Mary delivered software successfully because she was a subject matter expert and knew what the customer wanted.

I designed, developed, and programmed control systems - flight systems - and led the development of a fault tolerant process control computer (www.triconex.com), where we built an operating system, IO board controls using INTEL 8051, and a National Semiconductor (a CMOS version of the M68000) set of triple redundant processes. This was done in C with an embedded Real Time Operating system, WindRiver.

I can't remember having any formal specifications. We developed hardward, firmware, bent metal, developed the Control System OS, invented a programming language, developed a programming workstation on the original Compaq computer. All by simply "knowing" what to do because we had done it before, or we were literally inventing the future. We had SME's from our customers (Exxon, Boise Cascade, Shell, Total, and Elf). We had process engineers (ChemE's), we had RT OS developers from our previous defense systems. We had white hot C/Unix developers (the real UNIX, the one that came on a 9-track tape from Bell Labs).

But those days are over for lots of reasons.

1. The deep, and I mean really really deep, subject matter experts are rare these days. When we invented a schedule algorithm to maintain the real time response of all work in the OS, I took the code I had developed for missile guidance loops - keep the target inside the cone of the IR sensor while the AIM9L is on the wing of the F4D, and maintain that "lock" while the F4 flew away and the missile hit the "bad guy" in the ass. That kind of RT scheduling. I have neighbors here in Boulder that still do that for flight vehicle controls for special programs for special customers with three letter names. But in general this kind of software business it's not as common outside of special places in the US, like El Segundoa Blvd in LA.
2. We had direct control over the hardware. I mean at the silicon level. This is not possible today in normal computing
3. We were for the most part actual engineers. Physics for me, with digital signal process experience in grad school on particle accelerators. Others with EE, ChemE, process engineers, all of which had learned to write code. FORTRAN 77, PASCAL, Jovial, assembler, bit-slice (2901) microcode. But everyone was a hard core engineer at heart. One or two PhD's for reliability and safety. But no Computer Science, no home grown developers. Most developers are specialist in the development tools and some of the business process, but the "engineering" mind set is lost. There are some agile self-proclaimed voices that say software cannot be engineered. Which of course is complete BS, but they are out there shouting this nonsense, having never worked systems where "engineering" guided the development of an emergent product - you know, like flying to the moon.
4. The notion of a team was primary to our success. We had all come from large weapons systems, embedded control systems, and industrial environments. All knowing that people die - literally people die with the emergency shut down system fails to shutdown. Piper Alpha had occured a few year before. No prima donnas, no "I'm special because I wrote a book," or I've did one thing at one company and now I'm qualified to tell you what to do somewhere else.

So Mary is right, lots of software can be built without stories and detailed requirements. But that takes place ONLY because all that "stuff" is in the heads of the engineers and developers who have dome it before - succesfully do it before.

But now we work much more complex programs, systems where the lowest level components are well defined from the subject matter experts, but the integration of those components is complex and evolving.

Mary's quotes Gilb and Brooks is right on. In our Aerospace and Defense business this is RARELY the case. Embedded or Software Intensive systems have a tight connections between "engineering" of the systems and the "design" of the systems. These systems are developed incrementally and itertaively. This is the fundamental principle of Systems Engineering, the V-Model, and the Integrated Master Plan / Integrated Master Schedule. As well "process is King," in our domain, so anyone wanting to skip the process can look for work elsewhere.

At the notional level this is how programs are run in the A&D and other Systems Engineering domains. This approach is Rarely found in the enterprise IT would, expect where enterprise IT is inside and A&D firm. When it says detailed design this is context and domain sensitive. On some embedded system, sysMl is used with UML to define all the interfaces between the components. In other domains, detailed design is down to the board level and timing diagram of the firmware controlled system that will be sent to an ASIC fab shop that converts software (Handel-C) to hardware.

The appropriateness of the level of design is always considered, since the programs are on contract for a delivery date, a target budget, and a specific set of performance parameters.

This concept is also missing from enterprise IT - the idea that the project is a "business," with a profit margin, an expected delivery date, and a minimal set of capabilities. I'd suggest that if projects were run that way, better results would appear. Things like "do the appropriate amount" of documentation. Since documentation doesn't fly to orbit, we do what is needed to get the space craft to orbit and that's all. Documentation is needed, but documentation that doesn't support the capabilities - fly to LOE - is a waste. Why this is not well understood outside our domain I don't know.

Bad Project Management is my guess.

Quote of the Day

Vision without action is a day dream. Acton without vision is a nightmare - Japanese Proverb

So when I here "emergent requirements," is the desired approach to software development, where is the system going? What is the vision to the resulting system? What will the system look like in terms meaningful to the stakeholders - the measures of effectiveness? In measures meaningful to the developers - measures of performance?

Is this emergent system a "junk yard dog?" and beautifully formed architectural structure, and collective of half formed ideas glued together as each idea "emerged" from the mind of the user?

A CIO with a Mission

When we read about innovative CIO's and their plans for increasing the efficiency and effectiveness of their organizations, I'm reminded of a CIO heard speak at a conference.

General Pollett is the Director, Defense Information Systems Agency. DISA is a combination of government, military, and contractors tothat, engineers and provides command and control capabilities and enterprise infrastructure to continuously operate and assure a global net-centric enterprise in direct support to joint warfighters, National level leaders, and other mission and coalition partners across the full spectrum of operations.

When we hear about CIO's and the difficulty of the job, think of General Pollett's responsibilities.

What Does "DONE" Look Like?

There is a discussion on the Agile Usability Forum about "done." Several interesting things:

1. Done is being discussed around what the team perceives as done for the day
2. A post Done is *not* about some feature being delivered in glorious perfection. Few are. Done is a tool for helping teams make decisions and be able to move forward.

Both of these are interesting in that they describe a world view of vague and incremental definitions of work completion criteria. Of course in the absence of Measures of Effectiveness and Measures of Perfomance, we're going to get these vague and "soft"definitions.

That's not a problem if the customer understands that their (the customer's money) is being spent "evolving" what done looks like.

This is a fundamental open issue for the agile development community. The immutable variables of any project, from writing software, to flying to the moon, to doing landscaping in our backyard, is there are only three coupled variables that drive everything

1. Time - when do you need this completed?
2. Money - how much money to you want to spend? How much money do you have to spend? How much money are you willing to spend?
3. Technical performance - what is the minimal technical performance you are willing to accept when you've spent all the money and are at the end of the time period?

The last question is open on every project. From some small XP project where the customer has little idea about what she wants until the code starts to appear, to the Project Orion manned space flight program that has "evolved" its requirements three major times since we started working the avionics suite going on 4 years now.

It's just part of the process. But to expect that there is no hard meassure of DONE is naive at best.

In the absence of those pesky technical performance measures, then the hard measures of "done" are when you run out of money and or time.

At the end of the day, not matter how unpleasant it is for agile software development, some form of Project Management is needed to answer those questions, manage resources in the presence of those questions, and "keep the project sold," to the folks with the money who are asking those annoying questions:

• When will you be done?
• How much is this going to cost me when you're done
• You are going to provide me with stuff I can use for my business, mission, promise to my boss or the American People, RIGHT?

Quote of the Day

From team member back from the field, having worked software updates to deployed systems. When we speak of agile and responding to customer needs as they emerge, there are simple problems and their are hard problems. Updating software in the field for operational systems where the "customers" have specific needs from their hands on experience.

I Don't Need No Stink'in Earned Value

Came across a nice You Tube video of applying EV. There are three simple reasons for EV to monitor a project

1. Knowing where you are against the plan
2. Knowing how much you spent against the budget
3. Knowing what is left to done

From these three you can forecast how long it's going to take to complete the project and how much it will cost to reach this completion date.

Now if you don't have a plan then who cares abotu knowing where you are in the plan. If you don't have a budget for the project, then who cares about where are in the budget. And if you are working on a "level of effort" project, then you don't care when you done.

So if you software development project is using agile - poor agile BTW - and you don't have a planned completion date, then EV adds no value. If you gile project has no budget - a Not To Exceed value - then you could care less about measuring budget performance. And most importantly, if your agile project is being driven by the customers requirements and those are changing all the time, then who cares about knowing about how much work is left, because there is no way to know this.

So EV is worthless in this context. - Yea Right

If you have a project where the requirements are emerging in the presence of no budget limits, call me, I want to work that project. How fun. I want to spend the customers money, react to the whims of the customer, and work to short term deadlines - sprints - and forget the long term commitments to stay on budget and complete on or before the deadline.

Yea Right

Projects are systems

When the agile community speaks about complex systems, chaos, and the management - or not management - of such thing, they rarely use the vocabulary of Systems Engineering or Systems Theory. As a systems engineer (MSSM 1980) I get a smile when I hear this sort of talk, naive at times, misinformed at others.The classic example of this is

For centuries, mathematicians have preferred to work with linear (ordered) systems, and they considered nonlinear (complex) systems to be in a special group [Appelo 2011].

This is course is simply historically and mathematically wrong.

Linear system constitute a very small fraction of the entire groups of systems observed in nature. Yet they are very important for engineers and scientists. [Opening sentence in Signals, Systems and Communications, Bahrs and Valkenburg, 1965. An undergraduate text book sitting in my library]

In the Bahrs and Valkenburg, after the introduction chapter on linear systems comes the Fourier (1768-1830) and Laplace (1749-1827) solutions to nonlinear systems in communications and dynamics. So that notion of linear systems and the preference of using them might be better informed with a class or two in "systems theory."

I'm preparing for a three day seminar, I'm presenting to engineers seeking to improve their management of large complex programs. These programs have software, hardware, systems integration, subcontracting, procurement of COTS components, emerging requirements, developmental technologies, and a bit of "rocket science" thrown in.

One fundamental concept is to see the network of activities, the people performing those activities, and the outcomes from that work effort as a "system," in the same way their product and processes to produce the product are a system. Here's a clip from the seminar.

The Program is a System is he foundation of increasing the probability of success. The example here has a linear transform function - the system response curve - used for illustrative purposes. Real systems have nonlinear system response curves.

But there is a fundamental theorem in the system business

Every function or waveform encountered in practice can always be expressed as a sum (discrete or continuous) of various exponential functions.

The is Fourier's theorem. With the Laplace transform, nonlinear differential equations can be transformed into algebraic equations and standard multiplication, addition, subtraction, and division operators used to find solutions, then the inverse Laplace transform used to convert them back to their differential equation form.

So In The End

We need to take care when over generalizing about systems and especially when applying this knowledge to actual complex systems like software and hardware projects. Here's some guidance:

• All numbers in a project - cost, schedule, and technical performance - are random variables
• The relationships between these variables can be linear, nonlinear, or combinations
• The statistical nature of the values and the coupling between the process is itself a random process.

This is a stochastic process - a time evolving probabilistic system with random coupled processes.

This is the basis of Complex Adaptive Systems, not the populist pseudo-science description. These systems have solutions, they have management processes, they are "controllable," so don't buy the notion that chaos reigns - it doesn't.

Quote of the Day

Why IT Projects Fail - No Systems Engineering

I'm working two proposals now (just one yesterday). One is for a public agency IT Program Management Office, the other is for a federal (military) supplier. The notion of systems engineering as the basis of all project processes is common in the defense and space business. It is completely missing in the IT world.

The concept of "engineering a system," is at the heart of all complex projects. All project, and especially complex projects are "systems." Managing the design, development, and deployment of these systems is the role of Systems Engineering.

Here are the 11 roles of systems engineering

1. Requirements owner
2. System designer
3. System analyst
4. Validation and verification engineer
5. Logistics and operations engineer
6. Interface management engineer
7. Customer interface
8. Technical manager
9. Information manager
10. Process engineer
11. Coordinator

These roles are critical to the success of any complex project. They can e performed by one person. Or they can be performed by a team of people for each role. But they must be performed.

The eleven roles is found in Twelve Systems Engineering Roles, Sara A. Sheard, Third Millennium Systems, Software Productivity Consortium, 1996

Portfolio Management and the Program Management Office

I'm working a proposal for a Program Management Office deployment in a government domain. While I've lead project portfolio management processes, the development of program offices, and the program management office itself, I come across two books that moved my understanding to a new level.

This book has a step by step set of process for standing up a Program Management Office. The idea of a PMO seems foreign to some, even undesirable in the presence of agile software development and the mythical agile project management.

But a PMO has one of several critical purposes in an enterprise organizations. This book and the next speak directly to those - which I'll summarize in a bit.

But first let me make a pitch that I've made in the past around the application of Agile Software Development. Agile as a set of practices has been shown to improve lots of things around "writing software for money." Not the least of which is the institutionalization of the incremental delivery approaches found in our aerospace and defense business.

In A&D Work Packages and the Tasks they contain have limited duration and most importantly measures of physical percent complete in units of measure meaningful to the decision makers. This last part is the Critical Success Factor for any project. The measures of progress using the passage of time and the consumption of resources is simply Bad Management.

As well without a mandated limit on the duration of the Work Packages, the natural tendency is to extend the length of work before there is a measurement of physical progress. Agile does this naturally. So does every Earned Value based program controls system for the simple reason that a formal report is due to the Government every 30 days.

The next book is about the integration of the Program Management Office with Project Portfolio Management. The critical success factor here is to move away from using the PMO and PPM for cost reduction and move toward throughput management.

The notion of cost containment is ill formed and counter to increasing business value. Throughput focuses on meeting organization goals. These goals should be defined in a strategy, which in turn should be defined in a Balanced Score Card style strategy document.

This is the way The Real Way is producing business value. Connect the Balanced Scorecard initiatives, with projects in the portfolio, then manage those projects using measures of physical percent complete.

In each book there is hands on advice for the deployment and application of Program Management Offices and Portfolio Management. This short blog cannot convey these processes or the importance of their application.

But here's a set of questions that must be answered for any organization to be successful in any project domain:

• What are the organization's strategy objectives?
• What projects are active today that support these strategic objectives?
• Can these projects be directly traced to an objective?
• What projects must  be completed to achieve each of these strategic objectives?
• Can you measure the performance of each project?
• Is there a mechanism for moving each project forward more rapidly?

Quote of the Day

Planning efforts can never go waste, if a detailed plan targeting activities that have to start, finish, and are in-progress is prepared and adhered to keeping the over all schedule in mind can generate wonderful results for the project, professional satisfaction for the team members and guaranteed ROI for the stakeholders.

- Atual Gaur, Project Manager

The notion of planning is somehow being disconnected from the execution process is seriously flawed. The Plan of the Week is one start. The iteration plan is obvious. The daily standup is a light weight plan. Atual speaks to the Daily Planning process. The Plan of the Day was applied during the last year at Rocky Flats to assure that the work - including software work - was kept on schedule.

Measuring Business Value

When we talk about "business value," and in the same sentence say Earned Value is not Business Value, therefore Earned Value is of no interest to the business, it's likely that we don't actually understand how projects are managed at the business or governance level. Both business facing and project facing measures are needed for success.

The "values" of interest to the business should be connected to the "business case." They need to answer the question why are we doing this project. While it is necessary to have a business case and hopefully define what business value means, it is FAR from sufficient for success of a business system project.

This is a common lament of those on the business side when encountering project managers. And even more so when encountering agile software developers. Both the project managers and the software developers have their "units of measure." These units are meaningful to the members of their domain - or at least we should assume so.

• Earned Value project managers speak in Cost and Schedule measures. Of course both cost and schedule in Earned Value is measured in "money." What does it mean to be $125,000 behind schedule? How much is an hour worth?
• Agile software developers speak in "story points." How many story points are there in the Estimate to Complete? They can say. They can say how many story points per iteration and provide an approximate forecast of when "done" will arrive. But how much will it cost to complete - the Estimate At Completion (EAC) of the financial view of the project?

There is a better starting point in trying to connect the project facing measures with the business facing measures of performance - the achievement of business value. This starting point is the Systems Engineering paradigm. This paradigm has "measures" that are connected to the participants. Here they are...

These measures define meaningful units that can be used by the decision makers to make decisions.

• Measures of Effectiveness (MoE) are stated in units meaningful to the buyer. They Focus on capabilities independent of any technical implementation. They are connected to the mission success. These 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.The MoE's belong to the customer.
• Measures of Performance (MoP) are attributes that assure the system has the capability to perform. They are an assessment of the system to ensure it meets design requirements to satisfy the MoE. These measures characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. MoP’s belong to the Program – Developed by the Systems Engineer, Measured By CAMs, and Analyzed by Program Planning & Control function.
• Key Performance Parameters (KPP) have a threshold or objective value. They characterize the major drivers of performance. They are considered Critical to Customer(CTC). They represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. The acquirer defines the KPPs during the operational concept development – KPPs say what DONE looks lik.
• Technical Performance Measures (TPM) assess design progress, Define compliance to performance requirements. TPMs identify technical risk. They are limited to critical thresholds and include projected performance. They are the attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.

So when someone speaks about "business value," or worse states Earned Value has no business in the business of developing software for business, ask a few questions just to clarify understanding:

• What are the units of measure we're using in this discussion. Without shared units of measure it's just blather.
• How are you assigning these units of measure to specific actionable outcomes that need to be made by the decision makers? In other words how can I know if the project is getting better or getting worse from my specific point of view?
• When you say "value" what are the units of measure, how did you derive these, are they in fact meaningful to someone outside your domain of action (developer, cost analyst, CIO)?

Now you may not be interested in Estimates At Completion (EAC), Estimates to Complete (ETC), MoP's, MoE's, TPM's and KPP's. But someone better be interested if you're spending other people's money.

Project Management Success

The July 18/25, 2011 edition of Aviation Week & Space Technology has a Viewpoint article by Aaron Shenar titled "The Shuttle Era: Lessons Learned." In it he speaks of four lessons that are directly applicable to project and program success in any technical or business domain.

But first you need to read Aaron Shenhar and Dov Dvir's book Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation, Harvard Business School Press.

This book, along with IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, Peter Weill and Jeanne W. Ross, Harvard Business School Press, speak to the "decision rights" of managers and the resulting accountability that flows from those rights and the decisions.

The notion of "decision rights," emerged from studies of many 100's of enterprises around the world. Weill qnd Ross argue that IT business value (not to be confused with earned value), directly results from effective IT governance.

Governance is the firm's allocation of IT decision rights and accountability. Shenhar and Dvir speak to five strategies for successful projects:

1. Adopt the right management style for each project.
2. Understand the inherent uncertainties, complexities, and variables of each project.
3. Communicate unforeseen developments accurately to team members.
4. Identify the project's unique performance drivers
5. Strategically and realistically allocate project resources.

Project Management, Project Governance, and Agile

The notion that agile provides competitive advantage to IT organizations has merit. The notion that agile replaces project management and now it seems that agile replaces "governance," has no merit in the absence of tangible field evidence. There was a post this week about Australian banks moving away from Steering Committees. The notion of replacing a governance process with another process or no process needs to be tested in a variety of domains before we get too excited about a single instance.

Shenar's paper on "Mapping the Dimensions of Project Success," should be read before any decision is made around dropping those pesky steering committees.

The Three Lessons Learned

From Shenar's AW&ST article, here's the three (of the four) lessons learned.

1. Short trem efficiency will always result in long term, much bigger, and costly losses. The notion of avoiding "design up front," is just that notional. The statistically sound data that "refactoring" at the architectural level has yet to appear in any credible manner. The cost of change ALWAYS is higher later in the project.
2. Executive must listen to the engineers or developers. Without this communication channel the "real" status of a project, the "real" forecast performance and work effort will not be heard. When executives set goals that cannot be reached, they set the foundation for failure. No software development method is going to fix this. If you work in a place where unrealistic goals are the norm, think about finding new work - you're going to fail.
3. Developers must analyze the real challenges in their endeavors, and more importantly, find ways to communicate them well to decision makers. By "real challenges" I mean actual risks, their handling, and the plans for the handling. The notion that agile iterations have not cost, schedule, or technical margin is poorly understood outside domains where cost and schedule are managed on a weekly basis. Agile process are fundamentally Level of Effort. "We work down the story list until the money or time runs out." The notion that agile can provide "usable" product at the end of every iteration is wonderful. But the "minimum set of shippable features," needs to be delivered at the planned time for the planned budget. That requires planning, control, and corrective action.

These activities are called PROJECT MANAGEMENT. So when PMI speaks of the "role of project managers" in those Agile CoP webinars, they better be speaking about "project governance" and Decision Rights for the project.

Here's the papers from Shenhar around the topic of "project success."