Customers buy capabilities to accomplish a business goal or successfully complete a mission. Deliverables are the foundation of the ability to provide this capability. Here's how to manage a project focused on Deliverables.
Principles, Practices, and Processes to Increase Probability of Success
Customers buy capabilities to accomplish a business goal or successfully complete a mission. Deliverables are the foundation of the ability to provide this capability. Here's how to manage a project focused on Deliverables.
When I hear about requirements churn, bad requirements management - which is really bad business management, emergent requirements that turn over 20% a month for a complete turnover in 4 months - it's clear there is a serious problem in understanding how to manage the development of a non-trivial project.
Let's start here. Start with what capabilities does this project need to produce when it is done? The order of the capabilities is dependent of the business's ability to not only absorb the capability, but the value stream of those capabilities in support of the business strategy.
That picture at the bottom shows a value stream of capabilities for a health insurance provider network system. The notion of INVEST in agile has to be tested for any project. Dependencies exist and are actually required for enterprise projects. See the flow of capabilities chart below. Doing work in independent order would simply not work.
Writing software for money is a Closed Loop Control System.
Without the Desired State, the Current State, the comparison of the two, the Error Signal, the project is running open loop. We'll arrive when we arrive at the rate of progress we are performing at, for the cost we are consuming. There is no information available to show what the needed performance of cost, schedule, or value production needs to be to arrive, on time, on budget, and on value (or near enough to call it close).
And when you hear about control systems and they don't follow the picture at the top, they're not Closed Loop. They may be Open Loop, but they are not Close Loop.
Orion launched today and recovery after two orbits. The test of the launch system, Pad Abort system, and Heat Shield were the main purposes of the flight.
I worked the proposal - after coming off the winning proposal for Hubble Robotic Service Mission. The Crew Exploration Vehicle was the original name of the flight vehicle. The Integrated Master Plan and Integrated Master Schedule described the increasing maturity of the deliverables for the space craft and it's flight support systems. After the contract win, I moved to the flight avionics firm and defined the IMP/IMS and project performance management processes for that major subcontractor. When you get to minute 21:17, Tracking Data Relay Satellite is mentioned. I worked that project as a new graduate student many decades ago.
Starting back on TDRSS, agile - meaning emerging requirements, test driven development, direct customer feedback on short iterations - and the development process were deployed with rolling waves, 44 day rule Work Packages, and emergent technical requirements derived from Mission Capabilities.
Here's the long version of the launch to orbit.
After two orbits, Orion came home. The double boom is the sonic boom. Tests of the heat shield will confirm if it functioned properly.
Recently a statement was made about agile and complexity and it was conjectured if the project is too complex for a physical board - a place to put the stickies for the stories - then we've missed opportunities to simplify. Possibly not realizing that complexity, as well as complex system, are the norm in many domains and complexity management processes using tools - rather than manual means - is also the norm.
If your Agile planning needs are too complex for a physical board, you've probably missed opportunities to simplify / improve.
When I suggested that agile and agile tools are used to deal with complex problem in these environments, without the need to reduce that complexity, there was a conversation of sorts that suggested...
I'd be surprised to hear Orion was using a COTS Agile project management tool in a significant way
Some Necessary Complexity
On Hubble mission, there is a Service Mission Assurance Process that reveals some of the complexity of the System of Systems found in space flight. The Interface Control processes for example for the payload on STS 125.
External knowledge of what tools were used, what processes were applied, how the flight avionics software for Orion was converted from the 777 suite to the spacecraft suite, tested, altered to user needs, simulated, emulated, verified and validated on rolling waves, on 44 day iteration cycles could have only been obtained if you were actually in the building in the vendors shop.
But there are other surprises in the business of space flight. A few good places to start include:
Beyond the outsiders comments of surprise inside space and defense firms, agile tools from Rally, VersionOne, and JIRA are used in a wide variety of domains from embedded systems to intelligence systems, where the requirements don't come from the users, they come from the enemy. Here's an example of agile in the INTEL business.
Maybe those surprised by the many different applications of the principles of agile - developed long before the Agile Manifesto - missed those processes in Building O6, Sepulveda Blvd, Redondo Beach, circa 1978.
In The End
There are numerous approaches to applying agile development in a wide variety of domains. I work in a domain where Systems Engineering and Earned Value Management is the starting point and Agile is used to develop code guided by EAI-748-C and DID 81861.
In these environments, development of software is incremental and iterative, with emerging requirements, with stable capabilities. These programs are complex and tools are the basis of success for managing all the moving parts of the program. Rarely is everyone in the same room, since these are System of Systems programs. As well Integration and Test are done by external sources - V&V for flight safety. So many of the processes found in small commercial projects are not applicable to programs in our domain.
To suggest there is but one way to reduce complexity by putting all the stories on cards on the wall is a bit naive in the absence of establishing the external needs of the project first, then deciding what processes to apply.
Some background on applying agile in the DOD can be found at:
Domain first, Context second, Only then Process
When we read on a blog post that estimates are not meaningful unless you are doing very trivial work, † I wonder if the poster has worked on any non-trivial software domain. Places like GPS OCX, SAP consolidation, Manned Space Flight Avionics, or maybe Health Insurance Provider Networks. Because without some hands on experience in those non-trivial domains, it's be hard to actually knowing what you're talking about when it comes to estimating the spend of other peoples money.
Maybe some background on estimates for nontrivial work will shed light on this ill informed notion that only trivial projects can be estimated.
These are a small sample of papers from one journal on software estimating for misison critical, some times National Asset projects.
Go to Cross Talk, The Journal of Defense Software Engineering, and search for "estimating" to get 10 pages of 10 articles on this topic alone. This notion of estimating in non-trivial domains is well developed, well documented, and many examples of tools, processes, and principles.
If Do Your Homework and the Test is much easier.
It could be that the original poster has little experience in mission critical, national asset, enterprise class, software intensive systems. Or it could be the poster simply doesn't know what making estimates for project that spends other peoples money, many times significant amounts of money, is all about.
And of course most of the problems describes as the basis for Not Estimating - the illogical notion that if we can't do something well, let's stop doing it - starts with not knowing what Done Looks Like in any units of measure meaningful to the decision makers.
So start here with my favorite enterprise architect blog amd his list of books when you follow the link to the bottom.
So when you have some sense of what DONE looks like in terms of capabilities, the estimating process is now on solid ground. From that solid ground you can ask have we done any like this before? Or better yet can we f ind someone who has done something like this before? Or maybe can we look around to see what looks like our problem and figure out how long it took them by simply asking them? I
If the answer to any of those questions is NO and you're NOT working in a research and development domain, then don't start the project because you're not qualified to do the work, you don't know what you're doing and you're going to waste your customers money.
† Scroll to the bottom of http://zuill.us/WoodyZuill/category/estimating/ and search for "A Thing I Can Estimate," to see the phrase, and remember the questions and the answers above. If you're not answering those in some positive way, you're now on a death march project starting day one, because you don't know what done looks like for the needed capabilities. Not the requirements, not the code, not the testing - that's all straight forward. Without some notion of what the system is supposed to do, you're never recognize it if it were ever to come into view. And since the customer doesn't know as well, all the money they're spending to find out has to be written off as IRAD or flushed down the toliet as a waste of time and effort in the end. And then you'll know why Standish (improperly) reports projects fail.
If we were setting out to build a home, we would first lay out the floor plans, grouping each room by function and placing structural items within each room according to their best utility. This is not an arbitrary process – it is architecture. Moving from home design to IT system design does not change the process. Grouping data and processes into information systems creates the rooms of the system architecture. Arranging the data and processes for the best utility is the result of deploying an architecture. Many of the attributes of building architecture are applicable to system architecture. Form, function, best use of resources and materials, human interaction, reuse of design, longevity of the design decisions, robustness of the resulting entities are all attributes of well designed buildings and well designed computer systems. 
In general, an architecture is a set of rules that defines a unified and coherent structure consisting of constituent parts and connections that establish how those parts fit and work together. An architecture may be conceptualized from a specific perspective focusing on an aspect or view of its subject. These architectural perspectives themselves can become components in a higher–level architecture serving to integrate and unify them into a higher level structure.
The architecture must define the rules, guidelines, or constraints for creating conformant implementations of the system. While this architecture does not specify the details on any implementation, it does establish guidelines that must be observed in making implementation choices. These conditions are particularly important for component architectures that embody extensibility features to allow additional capabilities to be added to previously specified parts.  This is the case where Data Management is the initial deployment activity followed by more complex system components.
By adopting a system architecture motivation as the basis for the IT Strategy, several benefits result:
Peter Kretzman has a nice post in his series on #NoEstimates. Peter and I share a skepticism of "making decisions in the absence of estimating the cost and impact" of those decisions. In Peter's current post there is a quote that is telling.
Let’s use Ron Jeffries’ statement as an example of this stance:
“Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. “
One of my 3 half time jobs is working in the space and defense program performance management domain, both embedded systems and enterprise IT systems. DOD is the largest buyer of ERP on the planet. In this domain we have a formal process for determining what went wrong. The department looking after this is called Performance Assessment and Root Cause Analysis (PARCA). PARCA provides Root Cause Analysis for programs that have gone Nunn McCurdy as we would say.
When you read the reports from Rand and Institute for Defense Analyses on N-M breaches, requirements instability is in the top 5 as root causes.
It seems to me - in my narrow minded program performance management view of the world - that unstable requirements being used as the reason for vague estimates is so obvious a problem that has been completely ignored by the #NoEstimates advocates. It's like the olde saw
Doctor, Doctor it hurts when I do this (make estimates in the presence of vague requirements). Then stop doing that!
The notion of Capabilities Based Planning is missing in many software organizations. So having vague requirements is a natural outcome of not having definitive understanding of what Capabilities the system must provide, in units of measure meanigful to the decision makers. These units are:
Without these requirements have not home, are vague, and therefore create the root cause of bad estimates.
So what would a logical person do when working on a project that spends other peoples money, sometimes lots of other peoples money? Not Estimate? Does that sound like the corrective action to the root cause of the problems with software project success shortfall?
Not to me. It's the doctor, doctor this hurts paradigm. So until the root cause is determined, the corrective actions identified and applied, there can be no credible solution to the estimating problem. And there is a huge estimating problem in our domain, just read the N-M reports at RAND and IDA (Goggle nunn-mcurdy Rand or IDA to find them). Similar assessments of root causes can be found for enterprise IT from many sources.
The #NoEstimates advocates are attempting to solve the wrong problem with the wrong approach. They've yet to connect with the core process of writing software for money - MicroEconomics of software development. Here's a starting point to address the root casue rather than the symptom. Fixing the symptoms does nothing in the end. It just spends money, with no actonable outcomes. And that woudl be very counter to the principles of Agile.
This is one of those pictures tossed out at some conference that drives me crazy. It's uninformed, ignores the disciplines of developing software for money, and is meant to show how smart someone is, without actually understanding the core processes needed for actually being knowledgeable of the topic - in this case statistical processes of project work. Then the picture gets circulated, re-posted, and becomes the basis of all kinds of other misunderstanding, just like the Dilbert cartons that represent cartons of the problem, but have no corrective actions associated.
It is popular in some circles of agile development to construct charts showing the strawman of deterministic and waterfall approaches, then compare them to the stochastic approaches and point out how much better the latter is than the former. Here's an example.
These strawman approaches are of course not only misinformed, they're essentially nonsense in any domain where credible project management is established, and the basis of the their response with Don't Do Stupid Things on Purpose.
Let's look at each strawman statement for the Deterministic View in light of actual project management processes, either simply best practice or mandated practice.
The only explanation here is the intentional ignorance of basic science, math, engineering, and computer science.
In the stochastic View there are equally egregious errors.
In the End
For some reason using charts like this one, re-posting of Dilbert cartons, making statements using buzz words - we're using Real Options and Bayesian Statistics to manage our work - are may favorite ones - seems to be more common the closer we get to the sole contributor point of view. Along with look at my 22 samples of self-selected data with a ±70% variance as how to forecast future performance.
It may be because sole contributors are becoming more prevalent. Sole contributors have certainly changed the world of software development in wasy never possible by larger organizations. But without the foundation of good math, good systems engineering - and I don't mean "data center systems engineering," I mean INCOSE Systems Engineering - those sole contributor points of view simply don't scale.
Always ask when you hear a piece of advice - in what domain have you applied this advice with success?
We're preparing for a Webinar on 25 September 2014, now titled Using Techncial Performance to Inform Earned Value, which addresses the disconnect in EAI-748-C between two statement
Two reconcile these two statement, we need to have a process of informing Earned Value (BCWP) with the Techncial Performance of the products being built. After the Webinar, we'll post the link.
In the mean time here's a list of resources gathered to support this topic.
Much of the objection to SAFe comes from its seemingly Top Down paradigm. Many agile voices object that this approach is not agile, in the way they define agile - individual teams making their own decisions about what to do with their customer.
The domain of this bottom up approach is usually not well defined, other than the classic eXtreme Programming or the Agile Spectrum of Guy Strelitz where Co-Hacking is on the left, where the developers live by the pure agile manifesto.
But what happens when agile is applied to an enterprise development effort. One where the business needs define the capabilities that are not emergent, but rather they are needed to fulfill the business strategy or the mission of the organization. Then another paradigm emerges. One where higher order questions, frameworks, framing assumptions, governance, and other externalities trump the needs of the individual team.
Here's one approach that has served us well over time.
The statement is a bit off, since it's the Capabilities that are defined by the business. These capabilities are then turned into requirements, which may in fact emerge, which themselves are turned into working software. Starting with the capabilities, an enterprise software development effort means re-looking at the agile manifesto statements.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity - the art of maximizing the amount of work not done - is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
So What Does All This Mean?
Without a domain, hard to assess the applicability and appropriateness of much of anything.
What this really means of Scaled Agile Framework is the place to start for the enterprise.
When it is mentioned project management is a control system many in the agile world whince. But in fact project is a control system, a closed loop control system.
Here's how it works.
Each of these elements has some unit of measure:
Here's a small example of incremental delivery of value in an enterprise domain
The accomplishment of a mission or fulfillment of a business strategy can be called the value produced by the project. In the picture above the value delivered to the business is incremental, but fully functional on delivery to accomplish the business goal. These goals are defined in Measures of Effectiveness and Measures of Performance and these measures are derived from the business strategy or mission statement. So if I want a fleet of cars for my taxi service, producing a sketboard, then a bicycle, is not likley to accomplishment the business goal.
But the term value alone is nice, but not sufficient. Value needs to have some unit of measure. Revenue, cost reduction, environmental cleanup, education of students, reduction of disease, the process of sales orders at a lower cost, flying the 747 to it's destination with minimal fuel. Something that can be assessed in tangible units of measure.
In exchange for this value, with it's units of measure, we have the cost of producing this value.
To assess the value or the cost, we need to know the other item. We can't know the value of something without knowing its cost. We can't know if the cost is appropriate without knowing the value produced by the cost.
This is one principle of Microeconomics of software development
The process of deciding between choices about cost and value - the trade space between cost and value - starts with information about both cost and value. This information lives in the realm of uncertainty before and during the project's life-cycle. It is only known on the cost side after the project completes. And for the value may never be known in the absence of some uncertainty as to the actual measure. This is also a principle of microeconomics - the measures we use to make decisions are random variables.
To determine the value of the random variable we need to estimate, since of course they are random. With these random variables - cost of producing value and the value exchanged for the cost, the next step in projects is to define what we want the project to do:
The actual delivery of this value can be incremental, it can be iterative, evolutionary, linear, big bang, or other ways. Software many times can be iterative or incremental, pouring concrete and welding pipe can as well. Building the Interstate might be incremental, the high rise usually needs to wait for the occupancy permit before the value is delivered to the owners. There is no single approach.
For each of these a control system is needed to assure progress to plan is being made. The two types of control systems are Open Loop and Close Loop. The briefing below speaks to those and their use.
Why is it hard to think beyond our short term vision? Rapid delivery of incremental value is common sense, no one would object to that - within the ability of the business to absorb this value of course. This is called the Business Rhythm.
But that rapid redelivery of incremental value is only a means to an end. The end is a set of capabilities of the business that allows that business to accomplish their Mission. To do something as a whole with those incremental features. That is turn the features into a capability.
Think about a voice over IP system, who's feature set was incrementally delivered to 5,000 users at a nation wide firm. This week we can call people, receive calls from people, but we don't have the Hold feature yet. Are you really interested in taking that product and putting it to use?
How about an insurance enrollment system, where you can sign up, provide your financial and health background, choose between policies, but can't see which doctors in your town take the insurance, because the Provider Network piece isn't complete yet.
These are not notional examples, they're real projects I work on. For these type projects - most projects in the enterprise IT world - an All In feature set is needed. Not the Minimum Viable Product (MVP). But the set of Required Capabilities to meet the business case goals of providing a service or product to customers. No half baked release with missing market features.
You might say, that incremental release of features could be a market strategy, but looking at actual products or integrated services, it seems there is little room for partial capabilities in anything, let alone Enterprise class products. Either the target market gets the set of needed capabilities to capture market share or provide the business service or it doesn't and someone else does.
An internal system may have different behaviours, I can't say since I don't work in that domain. But we've heard loud and strident voices telling us deliver fast and deliver often when there is no consideration for the Business Rhythm of the market or user community for those incremental - which is a code word for partially working - capabilities.
Of course the big bang, design, code test, paradigm was nonsense to start with. That's not what I talking about here. I'm talking about the lack of critical assessment of what is the value flow of the business and only then applying a specific set of processes to deliver that value. Outcome first, then method.
So Now The Hard Part
The conversation around software delivery seems to be dominated by those writing software, rather than by those paying for the software to be written. Where are the critical thinking skills to ask those hard nosed business questions:
Questions like that have been replaced with platitudes and simple and many times simple minded phrases.
The Death March project starts when we don't know what DONE looks like. Many of the agile approaches attempt to avoid this by exchanged not knowing for budget and time bounds. In the enterprise IT domain, those providing the money, usually have a need for all the features on a specific date to meet the business goal.
ICD-10 go live, new product launch enabled by new enrollment, Go Live of new ERP company wide, with incremental transition across divisions or sites. Maintenance support systems for new fielded products on or before products put into service - are examples of all features, on budget, on schedule.
The elicitation of the underlying technical and operational requirements has to be incremental of course, because knowing all the requirements upfront is just not possible. Even in the nth install of ERP at the nth plant, there will be new and undiscovered requirements.
It's knowing the needed Capabiliities of the system that are the foundation of project success.
Here is a top level view of how to capture and use Capabilities Based Planning in enterprise IT.
This book starts with the hypothesis put forth by Theory of Project Management: Explanation of Novel Methods, in which it is conjectured that traditional project management processes are now obsolete and new project management processes are needed. Agile of course is one of those suggested.
This theory is the basis of a product, Last Planner used in the construction business.
There are some fundamental flaws starting on page 1 of the eBook, where it is asserted Project Management can be divided into main components:
The first is nearly universal, projects are the basis of most business processes, other than production and even then, projects are used to establish the production processes. The second part is domain dependent. In the eBook, it is conjectured that the view of projects rests on the assumptions listed in the orginal paper:
First let's look at these assumptions from a theory testing point of view. If these assumptions are found to be flawed, then what follows in terms of seeking new ways, may be based on unfounded assertions.
So Now What?
With the basis for seeking a new and innovative project management process grounded in assumptions that are not actually correct, is there any reason to continue reading the eBook?
Yes, for one simple reason. To put into perspective the notion of chaos as the basis of any credible probability calculaton for the success of a project.
Let's review the assumptions that are suggested as the reason to abandon the current project management approach and move to something else.
These assumptions — wrongly described — are then challanged by the Agile Communities approach.
Let's start with a framework, well developed in many domans - Capabilities Based Planning. In this framework, we don't start with the requirements. We start with the needed capabilities that will result from the project's outcomes. Let's look at the challanges above in light of Capabilities Based Planning.
Projects have lots of problems - symptoms actually - with root causes. But with the assumptions that are the basis of the paper and the eBook, one primary root cause is simple ...
BAD PROJECT MANAGEMENT
So do we move on to the next project management method before to assess the root causes of the current symptoms, fix the root causes and reassess if the current method has shortcomings? Let's hope not.
Here's the Principles, Practices, and Processes needed to increase the probability of project success. Apply these first, see if they are found wanting for the domain you work in. If so, assess then before abandoning them for others that must first be tested to improve the probability of success before jumping on that band wagon.
The common practice of starting with requirements leads to the common complaint that requirements change, we don't know what we want yet, our users aren't very good at defining requirements so we'll let them emerge. While these are common, they are usually a symptom of a missing piece of information.
We don't know what capabilities are needed and what is the Concept of Operations that those capabilities will implement, the project as likely failed before it starts. If we do know the Capabilities and the Concept of Operations, we can then measure progress of our work effort, not in the passage or time, consumption of resources (including money), or the production of stories or story points (which are unit-less and therefore pretty much meaningless to those paying the our work), but in Measures of Effectiveness, Measures of Performance, and Technical Performance Measures..
Concept of Operations
Let's start with a formal defininton of the Concept of Operations
What this tells us is that we need to start with what DONE looks like. DONE is not a set of features. DONE is not stories or story points. DONE is not modules, databases, bent metal. DONE is the ability, the capability to do something of value in echnage for the money we've spent.
The assessment of a capability is it's Measure of Effectiveness. 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. We need to define these upfront. The Measures of Effectiveness:
They are not emergement. They are descriptions of success. When we treat them as emergent, our project is chasing a moving target and is headed to the ditch.
Next are Measures of Performance. They characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. The Measures of Performance are:
Next comes the Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. The Technical Performance Measures:
Notice we have not mentioned coding, development methods like Scrum or XP, teams, paired programming of anything to so with building code. With these items in place, all those activities have no reason for being, other than to consume money and pass time. None of those items having anything with moving the project toward DONE, other spend money and pass time. Oh, you'll get a pile of stories implemented. Are they the right stories? How would you know. You'll perform lots of Test Driven Design. Is is the right design. How would you know?
Oh your customer is going to prioritize those stories and features. How are they going to know in the absence of knowing what DONE looks like.
Capabilities Based Planning
This has been presentde before, but now it has a reason - the Concept of Operations.
We Know the Answer To That Rights?
Lot's of myth floating around about requirements elicitation and management. Starting with requirements is not how large, complex, mission critical DOD and NASA programs work. Start with Capabilities. This cna be directly transferred to Enterprise IT.
Here's a map of the planned capabilities for an ERP system. This figure is from Performance-Based Project Management® where all the deatails of this and other principles, practices, and processes needed for project success can be found.
Here each business systems capability is outlined in the order needed to maximize the business value. In agile parlance, the customer has prioritized the deliverables. But in fact the prioritization is part of the strategic planning needed to assure that the cost investment returns the maximum value to assure the business receive maintains a positive ROI throughout the life of the project
The first step is to identify the needed capabilities. Here's the steps
Only when we have the capabilities defined for each stage of the project can we start on the requirements. All the capabilities need to be identified and sequenced, otherwise we can't be assured to business goals can be met for the planned investment. With the planned capabilities, we can start on the requirements
With requirements in place for each capability, we can then start development. This is done incrementally and iterative using our favorite agile method. Doesn't mater as long an incremental delivery of value of the approach.
From the anarchy of gaming coders sitting in the basement of the incubator on 28th and Pearl Street here in Boulder to the full verification and validation of ballistic missile defense system software, 7 miles up the road.
When I hear about how software should be written, how teams should be organized, how budgeting, planning, testing, deployment, maintenance, transiston to business, transistion to production, sustainment, and the myriad of other activities around software development should be done - the first question is always - what's the domain you're speaking about.
Then - have you tested these ideas outside our personal experience. And finally have you tested these ideas in another domain to see if they carry over? If you're just exploring ideas, no problem. But that limits the credibility of the idea to being just and idea with no actionable outcome, other than a conversation. Those paying for the software you are writing for money, usually don't like paying for you to explore using their cash - unless that effort is actually in the plan.
There are of course fundamental - immutable actually - principles for any project based endeavor. These are the Five Immutable Principles of all project success, shown over and again in the root cause analysis of failed projects.
All five of these principles need answers if we're going to have any hope of success. No matter how often it is repeated, insisted upon, or how clever the message is trying to avoid these principles, they're not going away. They are immutable. They need to be answered on day one and on every day until the project is over.
So if we are writing software for money - internal money, external money, maybe even our own money - ask these questions and see if our answers are credible.
More in next post about the economics of writing software for money.
I heard this phrase in a conference call yesterday with a DOD client and thought, how clever I'll write a blog about this. Only to find out there is a Forbes article with same name and several other articles as well.
The Forbes article had a case study about doing it right around a business process. It was the perfect framework (repeated here) for applying Performance-Based Project Management®
In the Forbes article there are five steps:
In the end project success is about knowing what done looks like, knowing how to get there, how to measure progress along the way. And of course knowing impediments to progress and handling them. These concepts are instantiated in two papers from a colleague Pat Barker, What is Your Estimate at Complete and Program Master Scehdule Can Improve Results, on page 20.
Much of the discussion on building products and services is focused on eliciting requirements, developing solutions around these requirements. Ignoring for a moment the silliness of not knowing the cost or duration of this work effort, we still need to address the business side of spending other peoples money in exchange for delivery a known value.
Over the past months I've come to see the world through the eyes of Systems Engineering. I have a MS in Systems Management, but haven't applied it in 25 years.
My current assignment is on a large software intensive system that is a national asset. This is a code word for it has to work as planned or 100's of million of people, sovereigns, and other users will be disappointed at best and possibly be put in harms way at worst.
This systems view means: (Systems Thinking for the Enterprise: New and Energing Perspectives)
So it all comes down to this:
If you don't know what someting costs - in units of money, schedule, manpower, infrastructure, tools, process risk, delay - you're not going to be able to know what it is worth.
That's it, It's that simple. Anyone suggesting their processes or even a HashTag masquerading as a suggested approach to problems, that this solution will increase the Probability of Project Success (POPS) or their suggested solution is focused on providing value to the customer, must address how that suggestion will work in the presence of the reality of building products and services in exchange for someone else's money.
The common picture of requirements elicitation looks like this. Which of course is an example of doing stupid things on purpose. When this picture is used as an example of not doing something because it doesn't turn out right, is a further example of doing stupid things.
Let's see where the gaps appear that results in the outcome in the last panel:
The wheels fall off when there is no description of DONE shared between the customer and the provider. If the customer doesn't know what DONE looks like, who does? The developers? Probably not. Is DONE emerging? Then the customer has to pay for that?
There is no way out of the need to know what DONE looks like in Measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures. Without these the success of the project is in doubt from the start.
The notion that requirements emerge is will established. But the capabilities the customer needs to be stable enough to establish an Estimate At Complete and an Estimated Duration to Complete. Without these the customer has no understanding of the all in cost of the project. These change as the requirements change. That's part of the project management process. This can't be ignored if the customer is to have any confidence in the project providing value at the needed time at needed to be put to use.
So a reminder one more time...
You can't assess the value of the project outcome without knowing something about the cost to deliver that value and the time frame for that delivery.
No matter what anyone says, this is an immutable business principle. Anything is simply fooling yourself into believing that the customer doesn't care how you spend her money or when you spend it.
Focus on value, that's what the customer bought. Actually they bought a capability to do something to improve their business or mission. But ignoring the cost of delivering that value is ignoring the balance sheet of the business.