Herding Cats

20 Reasons Managers Fail and Ways to Fix Them

The Wisdom Journal posted a nice article on the 20 Reasons Managers' Fail. The response to these failures have themselves failed in a common manner. It goes like this. State the failure mode. Use the phrase "don't do what you see in the failure mode." This is the same as "doctor, doctor it hurts." "Then don't do that."

From my point of view in Program Planning and Controls here's some suggestions using the mechanisms of PP&C to solve the problem – well most of the 20 failure modes.

Failure Mode	Solution Using PP&C
Avoiding responsibility when things go wrong by blaming others	Build a responsibility assignment matrix for every deliverable in the project. Use this RAM to also define all the project management process accountabilities. This leaves not work uncovered. Everyone can see in this big visible chart of who is accountable for what outcomes on the project.
Failing to develop and maintain a high level of morale among employees	Well this is harder and comes back to a leadership issue. Not direct solution here.
Incorrectly identifying solutions to problems	Using the Integrated Master Plan, define the Significant Accomplishment and most critically their Accomplishment Criteria. These criteria define beneficial outcomes of the project.
Unable to effectively deal with people. Shows up as being too blunt, showing favoritism, or being harshly critical. May manifest by making comparisons to other stores, departments, or people	This is a problem of leadership and isn't going to get solved by a process. Get better managers and staff
Unable to effectively plan and organize. Shows up as getting bogged down with details so that overall planning or organizing isn't done	Get a Plan, a real Plan. One that shows how the products and services increase in maturity as the work packages of the plan is executed.
Inflexibility. Will not listen to others. Is completely self-centered	Leadership again
Failing to encourage subordinates to contribute ideas and suggestions	Leadership again
Neglecting to develop a team effort	Use the responsibility assignment matrix to publically show how all the participants in the project make their individual and collective contributions. You can see directly who is overloaded, who is lightly loaded, where the power is concentrated. Balanced the power
Has a quick temper, is thin-skinned, easily upset, temperamental, or overly sensitive to criticism – real or imagined	Dump this guy like a hot potato
Failing to think in terms of the entire organizational situation. Doesn't see the bigger picture. Shows up as being unwilling to cooperate with other departments or managers. Thinks his or her department is the most important to the organization	Build a Work Breakdown Structure (WBS) Build an Organizational Breakdown Structure (OBS) Use these and the Statement of Work (SOW) to assure everyone and everything is covered
Failing to develop subordinates	Leadership again Use the RAM to designate subordinates
Having a lack of self confidence	Get better people
Lacking ability to express ideas either orally or in writing. Is unable to give clear and concise instructions to employees	Project management is a full contact sport Look for another job The evidence that communication is taking place starts with the physical elements of project management. A Plan, the WBS, OBS, and other artifacts that are built collectively by the project team in public meetings
Lacking follow-through. Doesn't check to see that instructions are complied with, that performance standards are met and that objectives are reached	Plan of the Week is the first step Maybe Plan of the Day for those with short attention spans No tolerance of missed deadlines – period. The project is lost a day at a time
Resisting change and is unwilling or afraid to try new ideas. Shows up as a resistance to training opportunities for the staff or for the manager	Leadership problem Get new members. Don't tolerate this – period
Is a poor decision maker. Procrastinates in making decisions or jumps to conclusions. Takes action without thinking through all possible reactions. May use emotions to make decisions	All decisions are public events. How the decision maker accountable. Poor decisions over time, means getting a new decision maker.
Is unable to follow instructions. Fails to listen or ask questions when needed to clarify a situation	"look for work elsewhere"
Is disloyal to the organization, its employees, superiors, ideals. Shows or expresses contempt for policies, superiors, or departments	"Look for work elsewhere"
Lacking motivation. Is not a self starter. Has to be told what to do, when to do it, and how to get it done	"Look for work elsewhere"
Dislikes added responsibilities. Fails to prepare for larger responsibilities and growth	You're not PM, "look for work elsewhere"

Now this is not the end all of solutions, but ignoring the bad leadership for the moment, the mechanics of addressing the other issues is staright forward.

One of the real problems in the softer side of project management, is we put up with bad behavior way too long. The answer is the doctor answer.

Doctor, doctor we have bad leaders, bad behavior. Then either get a new job or get a new leader. Don't not tolerate this. If you do, it's just an excuse and you get what you deserve – a failed project.

Anything That Is General Is Not Helpful

Sitting on the M/W/F morning proposal management call, with 30 or so participants, there was a comment made by one of the prime contractor proposal manager...

Anything that is general is not that useful

This triggered several thoughts:

1. When there is a generalized suggestion regarding project management with no actionable outcome - it's just that a generalized suggestion.
2. When there is a generalized suggestion to replace one process with another - it's just that a generalized suggestion.

The business of writing proposals - especially for US Defense Department customers starts with a structured method.

1. Each statement must have an unassailable beneficial outcome to the buyer
2. Each description of an activity should provide:

● Statement of the action
● Outcome from that action
● Benefit from the outcome of the action

If the conversations around project management, agile development, and many of the other topic of PM were to follow this paradigm, we'd get a lot more actionable information coming our way.

Managing in the Presence of Change

Managing in the presence of change is a core competency of any project manager. The complete myth that traditional project management - read PMBOK - tries to control change, to prevent change, or to avoid change all together is nonsense. No credible project manager or project management processes tries to prevent change.
    The challenge though is to manage in the presence of change. First let's look at a quote from a thought leader in the requirements business:

It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are revised, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are -- Karl Wiegers

Now with this stating point how can we manage in the presence of change?

• Establish a baseline for the project as we know it now? What have we committed to do? Without this knowledge, we can't determine the impact of change.
• Capture change requests through some formal method. In other words, no private change requests. It would fantasy to think a change would not impact cost, schedule, or some behavior of the product or service. So assessing the impact of the change is the first step of managing in the presence of change.
• With the change requests in hand, assess the impact on cost, schedule, and product behavior. Why are we doing this change? Does this change disrupt previous work, so we have rework? Does this change impact future work, so we have to replan? If we don't know the consequence of the requested change, then we can't make a decision about what to do next.
• Assess the change in the context of the larger picture. Will this change make the system less reliable? Less robust? Less attractive to the users? Less anything that we don't want to happen? But most of all will this change disrupt the architectural integrity of the system. This is a critical success factor for every type of system - software, hardware, operational. This integrity is the core attribute for making the system sustainable over it's life.

Now that we have a simple process for managing in presence of change. Next we need a process to deliver these activities:

• The Change Control Board is a simple process. This can be formal or it can be very informal. Formal means forms, meetings, signatures. Informal means face to face agreement of what to do next.
• Capture the approved decision in some way. Make sure everyone impacted by the change knows they are impacted by the change. Have them tell you they know they are impacted by the change.

This is the simplified approach to managing in the presence of change.

Collective Responsibility is No Responsibility

It dawned on me today the primary difference between agile management and actual management.

Collective Responsibility is No Responsibility

On our programs there is a single point of integrative responsibility - The Program Manager. The Program Manager is accountable for getting the program done. For getting the product delivered to the customer. For leading the team to the launch party.
    Of course there are many contributors to the success of the program. But there is only ONE contributor to the failure of the program - The Program Manager. Everyone knows this. Everyone accepts this. Every lives by this rule. Everyone supports the Program Manager. If they don't, they can look for another program to work.
    Why is it we get this confused in the agile IT world. Is there a different work ethic? A different egalitarian motivation is let people "try there hand," to learn by failing. Maybe.
    On the other side how do people "learn" in our world, if they don't fail?

Here's My Tale of How That Happens
    I was a young programmer. OK, not that young, having server a tour in Vietnam between undergrad and grad school. A fresh developer with a graduate degree in physics, who knew how to write a micro-coded version of partial differential equation solvers for digital signal progress algorithms. Finite Impulse Response Filters and Kalman Filters. Things found in particle accelerators - my dream job. But also found in radar signal processors. These filters grab signals from way below the noise and turn them into "targets" that the anti-missile systems to which they were connected shot at.
    Our job was to replace an analog system with a digital system. A simple job. Write a FORTRAN program and some assembly language I/O drivers that is an exact emulation of an analog computer and a bunch of analog filtering parts. This is the easy part. The hard part is to make this program performance the EXACT same function, with the EXACT same response times as the analog computer. No analog computers had been around a long. Our boss had designed and built most of the analog computers on this system and was now a "big wig" manager. We of course being fresh young student thought his bald head was an indication that his had missed the technology revolution of embedded microprocessor based digital signal processing. The AMD 2910 bit slice machine was going to make look really old when our cleaver machine made his analog box go away.
    Trouble with analog systems is their algorithms are embedded in the arrange of circuits. The math description of the system is written in a manual - a document of the process. You documentation of what the system did. And the other problem with analog systems is there cycle time is limited by the speed of light. Plus a bit if delay for the response time to signal level changes. A hell of a lot fast than a 2901 bit slice machine emulating the linear amplifiers, slope inverters, op amps, integrators, differentiators and the other parts that implemented the sets of partial differential equations used to point the radar and process the signals into targets.
    Well after several months of coding and testing we were ready to show off our work. Our boss stood in the corner of a very large warehouse sized room, with the radar antenna in the middle mounted on a hydraulic steering pedestal, maybe two stories high. When we turned on our "digital emulation" of the analog control system, the antenna spun around looking for the signal source and slamed into the spring stops, shaking the build, our teeth, or our bosses hat.
    He leaned against the wall, recovered is engloish dirving hat that he wore everywhere to cover his cue ball head, and simply asked:

You boys know what the hell you're doing?

    Why am I telling this story? Because he was responsible and accountable for the success of our little Internal Research and Development (IRAD) project. No sharred, collective, communal responsbilty. Just Fred (Fred Leary). And is question has never left me. We had on one answer - "I guess not."
    When people talk about collective responsbility of development teams I get an internal smile.
Oh you need to talk to Fred about that, I think to my self.
I'm he's long passed away. Our analog systems engineer, who designed and built F-86D flight controls.
    So when some says "we have a collective responsibity approach to software development," ask your self - "really and who do ask if they know what they doing?"

Bridge Building and Software Development

    There are vocal proponents that software development is unlike any other engineering process. This may be true, but for different reasons. I was reading a PhD Thesis from Robert Powell at the Stevens Institute of Technology. Powell's thesis is titled A Definition of High-Level Decisions in the Engineering of Systems.
    In the thesis was a brilliant set of statements. From the Standish reports (which of course have statistical confidence interval issues), approximately 85% of IT project fall short of achieving complete success. The problem with Standish of course is "success" is defined as On Budget, On Schedule. It does not take into account the other variables of a project. But that's another topic. I want to get to the bridge building processes.
    In the Standish report the failures are attributed to Human factors as opposed to Technology. In 1986 Alfred Spector, president of TransArc co-authored a paper comparing bridge building with to software development. Spector was the former Director of the Information Technology Center, Carnegie Mellon and is now a VP at Google.

    Bridges are normally built on time, on budget. Software never comes in on time or on budget. Spector found when a bridges falls down (or has technical and business difficulties) it is investigated, and a report is written on the cause of the failure. The resulting information is used to produce or refine the decision or decisions in an attempt to prevent recurrence of similar failures. This report becomes part of an architecture that is used to guide future decisions for successful bridge construction.

    However, in the computer industry failures are covered up, ignored, and or rationalized, which may be due to the absence of procedures for analyzing failures.

    Subsequently, due to he lack of a rational explicit process, the same mistakes continue to occur and negatively impact the success of software development projects. Because of human failings, critical information is lost, decision making becomes difficult, and mistakes are repeated. It is the repetition of mistakes and the occurrence of new ones, because of improper decision making, that result in canceled projects, cost overruns, time overruns, and failure to provide expected features.

A second reference is a US Air Force study stating three common reasons for software system development failure:

• Risks associated with teams - if the team of developers, acquirers, end user, and system maintainers had not worked together before and did not learn to communicate effectively, they were not likely to develop a successful system.
  
• Risk associated with technology - Teams that pursued a new technical approach (for
  example, the first foray into client-server computing) found that the lack of experience
  with a new technology, architecture, or development approach contributed to failure.
  
• Risks associated with requirements - the most often-cited reason for failure
  was poor management of requirements characterized by frequently changing
  requirements, requirements that were not well understood, and requirements proliferation

A KPMG report cites the principal reasons for failure among IT projects as poor project planning.

No project can really get off the ground without a valid plan. The project plan reflects many decisions made during the development process (e.g., compatible tasks, schedule, budgets, defined and acceptable risks, etc.) and a poor plan is simply a reflection of poor decision making.

So in the end it's not about developing the software. It's not about applying one method over another. It's about project planning, good requirements, and having teams that can work together with the technology selected for the project.

When someone says bridges are not software, they're right. Maybe software development should learn from bridge building and stop doing poor engineering processes. With the advent of COTS products as the basis of most Enterprise IT, it's time to stop making software "special."

If the software development business doesn't start behaving like they are building bridges - or other projects that increase the body of knowledge from their failures - no "magic beans" are going to improve the outcomes.

Following the PM Method

Ron Rosenhead posted a quote "Strict adherence to the project management methodology is more important than the delivering the project.
    At first I thought - naw that can't be the right way to go. Then a second later I thought, "yes that's exactly what we do."
    One starting point is to close the loop with the concept that "We adhere to the project management method over delivering the project outcomes" This of course depends on the domain and context:

• In FAR (Federal Acquisition Regulation) program, adherence to the PM method is mandated.
• At the enterprise project level for IT, adherence to PM method is usually mandated by the IT Governance policy

Now before all the agilest start foaming at the mouth, this approach is highly domain and context sensitive. Here's why:

• If I have a portfolio of projects in IT or a Program in defense then the underlying programmatic management processes need to be similar in some way to make comparisons of the performance of projects in the portfolio.
• On Defense and Space programs within the same company or possibly in the same business unit, business unit performance measures need to have similar underlying methods - again to have the same units of measure for all project or programs in the business unit.
• If I'm burning my own money (figuratively) then adhering to a consistent method over time is probably not that interesting. If I'm spending the public's money it's a different issue. By public this can mean tax payer - any tax payer - federal, state, local. Or stockholder.
• I'll go out on a limb a say that many of the "method wars" make no mention of the funding sources. They seem to be all about the developer or the individual.

In the end having one PM method works IF there are graded version of the PM method. These means:

• Methods are subsets of the largest set of process areas.
• Brookhaven National Laboratory produced a  Graded Application of Project Management method based on Department of Energy O413.3 and PMBOK that we used at Rocky Flats.
• This graded approach allows tailoring of the PM processes to fit the needs of the project.

In the end the PM method in an enterprise or large project environment should be followed OVER getting the work out the door. Getting the work out the door is necessary but not sufficient for sustainable performance of a project-centric business.

Specifications

    For all of us looking for specifications and documents that are usually buried in some web site or worse, available for a price, there's a source - EverySpec.
    Some things that were only available at IHS can be found there. The mythical ANSI/EIA-748-B is not.

Earned Value Issue of SoftwareTech

SoftwareTech is magazine from the Data & Analysis Center for Software, US Department of Defense, Rome Air Force Based, Rome, NY. The current edition is focused on Earned Value Management. There is one article on using earned value concepts in agile projects. Charts for Earned Value and Planned Value are used to show how the agile project is progressing. This approach is fairly benign in that it assumes "level of effort" consumption of labor resources, so no S-Curve is needed. The 0/100 percent completion is the right approach for EV, and the fixed periods of performance make it easy to compute the performance indicies.
    Paul Solomon has an article on "Applying Earned Value Management to Software Intensive Programs," that describes the more robust used of EV, using his Performance-Based Earned Value^tm (PB-EV) approach. PB-EV is one of the approaches we use in our Deliverables Based Planning^sm program management method as it is applied to DoD programs.
    This journal is free from DACS.

The other magazine that arrived in the mail today is Defense AT&L. This is published by the Defense Acquisition University. The DAU site has many useful sources for project and program management as well as the "human side" of these activities. This months edition is dedicated to just that "It's About People."

The Peter Principle Lives

Bob Sutton's Blog has a nice piece applicable to nearly every malady in today's headlines, from the financial crisis to failed project management.

In Praise of Simple Competence

Management of Projects

The conventional definition of management is...

To control and direct; to administer; to treat, as a person, with caution and judgment

The Software Engineering Institute's People Capability Maturity Model Integrated (P-CMMI) definition is...

To accept stewardship of a resource; to develop; to optimize the conditions affecting success

Restating the Obvious

Through a series of posts I came across an interesting site. www.typealyzer.com which will tell you what Meyers Briggs type you are from reading your blog.
    Well guess what, I'm INTJ.

The long-range thinking and individualistic type. They are especially good at looking at almost anything and figuring out a way of improving it - often with a highly creative and imaginative touch. They are intellectually curious and daring, but might be physically hesitant to try new things.
The Scientists enjoy theoretical work that allows them to use their strong minds and bold creativity. Since they tend to be so abstract and theoretical in their communication they often have a problem communicating their visions to other people and need to learn patience and use concrete examples. Since they are extremely good at concentrating they often have no trouble working alone.

    Not so sure about the theoretical part, since I earned my living in the science world as an experimentalist. Not too interested in new things these days. But at 61, I've had more then enough excitement to date.
    Pointed it at my home site www.niwotridge.com (ISTJ: The Duty Fulfillers) and or firms site www.lewisandfowler.com (ESTJ: Guardians). Another guardian is Lockheed Martin, one of our clients.

SEI Membership

    The Software Engineering Institute (www.sei.cmu.edu) is a source of the Capability Maturity Model Integrated (CMMI). CMMI is the basis of a process improvement framework used with success in many domains. There are other Matrity Models, including OGC's Project, Program, Portfolio Management Maturity Model (P3M3).
    SEI used to have a free membership. Now it costs. But there is still a free membership for veterans. You need to go to LinkedIn, look for the SEI Group, sign up. You'll get a message back - "this is a members only group," with a link to the applciation.
    Fill out the application, attach your DD214 and fax or mail it in. You'll receive a very nice email with the account information. Thanks to a work collegue who is a Marine - Semper Fi Mac - for pointing this out to us old guys.

Open Journals

Came across a useful link in my travels today looking for Earned Value and Earned Schedule papers

Directory of Open Access Journals

Why I'm Not a PMP

Raven Young posted a link observing my membership in PMI but no PMP after my name. I am a member of the ACM, IEEE, its Computer Society, American Physical Society and INCOSE. Each of these professional organizations has a technical journal that adds value to my work activities. I also subscribe to Scientific American, American Scientist, Sky and Telescope, and Aviation Week and Space Technology  and Physics Today along with Road, VeloNews, Bicycle, National Geographic, and a variety of news magazines. I'm the son of a University Librarian. I'm genetically wired to be a knowledge hound. I connect easily with the "theory of ideas" types. This was probably the reason why I wasn't a raving success on the PhD qualifier exam - not a source of truely orginal ideas needed to move up the food chain of particle physics.

But in the end I'm not a PMP.

Why?

I've never really given it much thought. I know PMP's, I work with PMP's, I've hired PMs with PMP's. Nothing in the PMBOK seems at odds with how I view the world of project management. For me personally PMBOK doesn't really have a lot to say about the project processes I use every day. In fact the DoD version of PMBOK pretty much replaces most of PMBOK verbiage with its own, keeping the chapter titles and overall structure.

I guess in the end the PMP moniker doesn't appeal to me that much. It seems to be a "gate keeping" type badge. I once tried to get grandfathered in as a Professional Control Systems Engineer. But my job changed and I didn't have enough practical hours to qualify in California and was sent to work in Ohio on a flight controls systems and lost interest. I know PE Structure engineers, I have several colleagues in Canada with PEs and their "iron ring." This idea is really useful - get a degree in some kind of engineering, do semesters of internship, write a serious paper in your senior year and take the PE test and you get to graduate. You're a practicing engineering as a new graduate. Great concept.

Me, I was a physics major who could program real time experiments, and then learned to manage software projects, got an MBA/Systems Engineering and moved into management. So what would a PMP offer me? Good question:

• Professional status - maybe if the PMP was in fact a Professional Engineering certification like the state administered PE
• Skills - not much to do there since the PMBOK and PMP are pretty rudimentary compared to the full up EV/IMP/IMS performance based contracts I work on
• New knowledge - not much there either compared to our multiple location, multiple IPT fully integrated weekly earned value execution programs

I'm not saying in any way I have skills and knowledge that are unique or special. I work for and with  planners, cost engineers, project and program managers that have 2 to 3 decades of experience. It's humbling to sit in a room discussing an issue and have someone comment about how that same problem was solved 23 years ago using a manual technique - everyone remember C/SCSC and line of balance?

So far I've not seen the need...or the advantage to my career... or that it distinguishes the holder in anyway dealing with the practical aspects of managing projects for money.

Pros and Amatuers

The road bike season is now in full swing on the Front Range. Kinetics is our "rite of spring" that actually had a nice day on Saturday. With this comes larger peletons starting to train for the events starting in June. My new ride has a few 100 miles on it and we're starting to train for those centuries and large group rides. This requires many miles and a selection of terrain to match the first ride - which for our group is Elephant Rock which comes some very "rolling" hills north of Colorado Springs. In the Rockies "rolling" means 1,000's of feet again over the course.

While on a training ride last week a large group caught up with us with their team jersey's on heading north on Highway 36 toward Lyons, just north of Boulder. This is small set of rolling hills on the way to Rocky Mountain National Park. There were several things to jumped out as we watched them pass us on an uphill strength:

• Everyone peddled smooth and steady with their tires tracking in perfect lines, two abreast, 4 deep, nice steady pull of the leads with the rest of grroup catching their breath from the previous climb
• No shoulder movement, no hip sway, no hint of bounce in the saddle, hip flexors doing most of the work and all in  unison nearly in the same gear.
• Small conversation between the 3 or 4 riders, no head turning, just chit-chat as they "motored" by. A pleasant "on your left," and good afternoon as they road over the next ridge, picked up the pace and disappeared down the road.

We had been dropped by pros, pleasantly dropped, but dropped all the same. We all know we're amateurs. We're not rank amateurs, but mostly 55+ amateurs, reliving our glory days when we were moderately successful Cat 4 riders. But watching a group of Cat 2's be pulled along by their Cat Pro/1 guides was pure heaven.

What Does This have to Do with Project Management You Ask?

There are pros and there are amateurs in every endeavor - on the roads north of Boulder Colorado and in the offices of corporations. "Posers" our 16 year old's call them when applied to clothes, cross country records and general teenage activities, where those who what to be something aren't there yet.

The Project Manager's may be "posers" as well. But the professional have several traits the amateurs doesn't:

• Command of the mechanics of project management. This includes all the process areas found in your favorite PM framework as well as other disciplines not found in the mainstream community. But the pros have more than just knowledge, they have the experience to know when to apply this knowledge and when to hold back to wait a bit for the problem to emerge before applying a solution. Like the Pro Peleton, the "professional" has "command" of the tools of his trade and applies them with grace, forthought, and ease.
• Deep insight into the emerging situation of the project. Using tools and data produced by the tools, the Professional "guides" the project along the path to success in ways the Amateur doesn't have a clue about. Like the Pro Peleton that cruised on by, the Professional makes it look effortless. When it fact it is wickedly difficult. This insight comes from observing other professional, experimenting, repetitive application of tried and true methods, taking good notes, perseverance, strength (both physical and mental in both cases), and an innate sense of "leadership" that comes from years if not decades of success along with all the near-successes that harden the professional against the natural failures of his avocation.

The amatuer waves around the flag of professionalism with the trappings of "I want to be like them." But in the end he really has not yet paid the dues to start on the ladder of improvement. Owning the certification may be necessary but not sufficient

The amatuer project manager:

• Measurees progress by the passage of time
• Develops no-slack schedules
• Assumes all tasks durations are deterministic

The Professional

• Measure progress through deliverables that define increasing maturity
• Builds a risk tolerant plan
• Understanding the difference between probability and statistics and builds a probabilistic plan that can be analyzed for implicit as well as explict risks

I'll never be a CAT 1/2 rider (although there is a 55+ category now). But like a Pro cyclist, the professional Project Manager must train hard, eat right, ride hard, have a keen sense of current situtaion, and stay focused in the goal of hanging in the middle of the peloton and waiting for the chance to move to the lead at the right time - not too soon, not too late.

Thinking like a Systems Engineer

The paradigm of systems engineering and agile development is starting to come together. "Some Future Trends and Implications for Systems and Software Engineering Processes," Barry Boehm, Systems Engineering, Volume 9, Number 1, 2006 presents and overview of how software intensive systems can be addressed through the processes of systems engineering.

This triggered a conversation about "what is systems engineering and why is it applicable to software systems development?"

Thinking Like a Systems Engineer Involves Some Core Concepts

1. Conceptualizing - systems engineers see the big picture. A problem may NOT be optimally be solved by breaking it into its elements and finding separate solutions. A "whole picture" needs to be constructed before solutions are proposed.
2. Requirements Analysis - requirements are the foundation of any project. Requirements analysis identifies and expresses verifiable statements of user needs in appropriate terms to guide the concept development.
3. Selecting Alternatives - systems engineering is about making trade offs between viable alternatives. Trade studies provide an objective foundation for the selection of one of the alternative solutions.
4. Optimization of the alternatives - searching for the "perfect" solution is a poor approach to problem solving. The notion of "optimum" is related to the notion of "tradeoff." For example synthesizing an architecture is essentially a tradeoff leading to a selected architecture.

What Does This Mean for Agile Project Management?

Agile and Systems Engineering are tightly coupled in many ways:

• Feedback
• Customer focused
• Value stream focus
• Emerging solutions
• Verifiable deliverables
• Performance based management
• Scalable processes

A critical concept in the Boehm paper is C2ISR (Command and Control, Intelligence, Surveillance and Reconnaissance). This concept is closely coupled with OODA (Observe, Orient, Decide and Act). Both are tightly connected with agile behavior. The OODA concepts emerged from fighter pilot training and C2ISR emerged from capabilities based planning in the defense domain.

If agile is looking for an execution framework in our to move beyond the "buzz words" of manifestos - these paradigms are a good starting points along with a "thinking" process of a Systems Engineer.

Value Centered Management

The agile community describes a "value focused" approach to management and development activities. While few would argue that the creation of value is not useful in managing projects, the question is what are the characteristics of these values?

A Systems Engineering paper, "Value-Centered R&R Organizations," William Rouse and Kenneth Boff, describes ten principles for characterizing, assessing, and managing value. These principles can be expanded to cover general technology development activities.

1. Value is created in organizations by providing "technology options" for meeting contingent needs of the enterprise.
2. Value focused organizations provide the primary means for the enterprise to manage uncertainty by generating options for addressing contingent needs.
3. A central challenge of a value focused organization is to create a portfolio of viable options; whether or not options are exercised in an enterprise challenge.
4. Value streams, or value networks, provide the means for representing value flow and assessing the value of options created.
5. Valuation of technology investments can be addressed by assessing the value of the options created by the value network.
6. Decision making processes - governance - are central in managing the flow of value.
7. Organizational structure affects value flow, with significant differences between hierarchical versus heterarchical structures.
8. Individual and team affiliations and identities affect value flow; dovetailing processes with disciplines is essential
9. Champions play important, yet subtle roles in value flow; supporting champions is necessary but not sufficient for success.
10. Incentives and rewards affect value flow; aligning these systems with value maximization is critical.

What's the Point?

When there is a suggestion that a process, tool or paradigm be applied to a problem, asking and answering the questions embedded in these principles will be useful.

• How can we generate value as part of the governance process?
• How can this value generation effort be traceable to a strategy?
• How can the organizational factors be aligned to support value generation?
• If a tool is being proposed, can the application of this tool be traced to a metric that in turn is traceable to value generation?

This last question is the show stopper question that must be asked to every process improvement product vendor.

Stats

Frank Patrick pointed out an economic statistics site that has many interesting numbers. One stat that directly impacts our work is the cost of living for the workforce and this cost's impact on recruiting. These and other costs have direct impact on the cost of labor and on very large programs (5 to 8 billion) this adds up over time and causes shifts in work and the work force.

Rechtin Dies

Eberhardt Rechtin died today. Rechtin was a Director DARPA, helped create the Goldstone Deep Space Network, was the Chief Engineer of HP, the CEO of Aerospace Corporation, and Assistant Director of the Jet Propulsion Laboratory. His book The Art of Systems Architecting is the basis an many a Systems Engineering Management Plan (SEMP). His Systems Architecting of Organizations: Why Eagles Can't Swim is a Systems Engineer's view of organizational development. No touchy-feely pseudo-science here but good basic engineering practices applied to business process improvement. This view comes for his decades of business development and interviews with CEO's of private, public, commerical and military organizaitons that operate in the ruthlessly competitive environment of aerospace and defense system, where most projects involve "betting the company" in a winner take all environment. larry Bosidy's Execution should sit along side Rechtin's books.

What's important here is more than Rechntin's accomplishments. He was a teacher of Systems Engineering as well as a thought leader. He was a Program Manager that delivered on the promise of space flight and space technology - Aerospace launched the first GPS systems under his tenure. He was Professor Emeritus at USC where he taught engineering theory to many students, graduate students and professionals (me being one).

The Art of Systems Architecting provides a framework for specifying, designing and managing complex systems. The chapters range from spacecraft to IT systems. The most important topics in the book include:

• The concepts for four (4) classes of methodology - Normative, Rational, Participative, Heuristic. This provides the basis for separating the processes of one perspective from another. For example when a agile proponent suggests that XP is applicable in a 21 CFR Part 11 software certification environment, the response might be "what perspective are you suggesting we apply of your method to our certification requirements?" There are horror stories of XP-style processes being dropped into a 21CFR environment - by well known agile leaders - with little or no understanding or consideration for the certification requirements of the resulting software.
• The concept of capturing the heuristics of design and implementation. His examples of spacecraft design, build and operate lays the foundation for other complex domains - IT being one. What Aerospace Corp as well as other leaders do is capture the heuristics of building these machines for future projects and future generations.

Anyone wanting to gain some insight into the world of systems engineering and the architecting of complex systems would be well served with Rechtin's current edition.

Best Evidentuary Materials

I think well of all skepticism to which I reply: "Let's try it." – Friedrich Nietzsche

When a suggestion is made that there is a solution to a long standing problem - such as productivity improvement or performance enhancement - my gut reaction is "really, you've shown that the improvement is connected to your process?"

A Physical Sciences Approach to Process Improvement

My core training (training is not the same as education BTW) is in physics. Experimental particle physics actually. This is where I learned to program - on a PDP-8M, doing Fast Fourier Transforms in 8K of 12bit wide memory, 125KHz 8-bit A/D converter, a Tektronix 4014 display and a pen plotter.

When someone came into the Principle Investigator's (PI) office with a picture of something new off the experiment - these pictures were taken with a Polaroid camera fitting to an oscilloscope. The first response would have been - go back to the lab and get me 3 more pictures just like that from your experiment. Do this with my RA watching you.

With those pictures in hand the next questions would be why do you think you should be seeing what you are seeing? This is where science is separated from conjecture, anecdotes and speculation. There needs to be a direct and traceable connection between cause and effect. Why should your proposed process actually result in improvement? This approach is very annoying to many in the process improvement or methodology business. They'll claim what they are doing is not science, engineering, or anything close. Rather "trust" me it works. Or "try it your self." Or the best disclaimer around "your mileage may vary."

In principle there is nothing wrong with this approach, in practice there is. Just don't bet your company or career on the process or method without first doing a bit of "experimenting" yourself. This is a good point to think of Nietzsche.

Like a very experienced risk analysis consultant said on our program

Can you introduce me to three managers on programs that have completed, that have used your tool or process?

The next step in the science lab world involves taking the experiment apart and putting it back together to see if it still behaves in the same way. Then having someone else take it apart and put it back together possibly on the other side of the country. With these steps in place, the theory of why and the practice of how need to be connected to make a projection of what else you should be seeing from the results.

This is the measurement problem with many process improvement initiatives. What should I be measuring? How can I connect these observed improvements with the underlying process

And the Point Is?

When there is a suggestion that a specific process or method provides an improvement - maybe through a case study - look deeper before nodding approval...

1. Was there a baseline to which to compare the new results?
2. Did this baseline contain really bad behavior in the first place? If so, then simply showing up and stopping the bad behavior would have resulted in some improvement.
3. Is the improvement statistically significant. a 155% improvement on a process that has 200% swings in performance may not be statistically significant.
4. Like the Fleischman and Ponds Cold Fusion experiment - can these improvements be repeated and sustained in the absence of the experimenter?
5. Is the experiment or case study really neutral regarding the result and the conclusion. The concept of an Independent Non-aligned Review is a power incentive here in aerospace not to cook the books regarding benefits of any process. Be wary strangers bearing gifts.

Postscript

There is much talk about how the Toyota Production System (TPS) works and how it can be applied to a broad set of applications. This link provides some background. The central philosophy of the TPS is the complete elimination of all waste. When the TPS is mentioned in a conversation about process improvement. Ask the speaker to described how exactly they propose to eliminate all waste in the new process, in practice not in theory.