Herding Cats

Finish to Start Is All There Is

I've discovered the site Mosaic Projects. There is a wealth of material that I'm starting to go through. A useful paper is titled Links, Lags, and Ladders. It is about the topology of project schedules. In Microsoft Project there are many ways to link tasks with each other. This paper describes a few and speaks to the outcomes of these choices.
    Here in Space and Defense, there is only ONE way to link work together.

FINISH to START

Now to say this is the ONLY way is a bit of a stretch, but every effort is should be made to use FS for task connectivity. There is one critical reason for this:

The start of any future work that depends partially complete previous work, usually results in rework.

To avoid rework, or at least intentionally caused rework, all future work should be dependent on 100% complete prior work. This does not mean rework will be avoided. Requirements change, defect are found, etc. But using anything other than FS intentionally sets up the conditions of rework for several reasons:

1. Future work is started with incomplete dependencies - FS minus X Days
2. Multiple work streams need to finish on or near the sane day - FF minus X Days
3. Multiple work stream start on or near the same time - SS plus X Days

Here's the challenge question for all network topologies.

What is the reason this work can start? In other words what is the driver of this work?

Wouldn't you want this reason to be based on a 100% completion of the dependencies? Would you want start work on partial information? This doesn't mean you have full information at the project level. No Big Design Up Front (BDUF) or Water Fall process. No this approach does not suggest that.
    But for the smallest granularity of work - usually the work package - a firm set of "starting" conditions should be in place. This is the key to deciding how to partition the work. On what sized boundaries should the work be planned? The answer is simple...
Partition the work on the largest "small" boundary that can be assured to be complete prior to starting the subsequent work. This is a trick answer of course, but one that shoudl guide the partitioning of the Work Packages. The useful answer is to partition the work on single deliverables. Deliverables that can be measured in units meaningful to the customer.
    The agilest software developers would call this "feature driven development." But a feature is usually defined, not has any quantifiable unit of measure. An since these features tend to emerge and are sometimes discourages from being described within an architecture, this is not very helpful.
    A systems engineering approach is more tractable. The size of the Work Package is the lowest element of cost in the system that can be identified with a lowest level requirement. The requirements flow down tree can be the guide here. This is not a hard and fast rule. Like all good guidance it  needs a context in which to be tested. And experience developing Work Package structures, WBSs and the sequence of work.
    But think about this in terms of "least complexity of the topology of the program." This is a coupling and cohesion discussion. Decrease coupling increase cohesion, and you're on your way.

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

A Resource for PM Materials

    I've been embedded on a proposal team of late as well as working on my presentation of EVM World 2009 and manning the booth at several trade shows - Space Symposium, Space Command. The result is a lack of ideas for posting. Instead I've been reading my Google Reader list and catching up on edits of our program controls handbook.
    What became clear was the resources available at Mosaic Project Services Pty Ltd. The first one is being used directly in some of our responses to scheduling issues on a large program. "Scheduling in the Age of Complexity," is a mandatory read for anyone interested in professional project planning and controls.
    Two things are important here. The paper is a nice survey with actionable materials. The PMI College of Scheduling requires a "paper" be submitted along with the presentation. Having presented at last years conference, writing the paper reveals many of the short comings of just standing up and giving a talk.

    The "talk" only approach skips all the nasty details like tying the themes together in a cogent thesis on the topic. Many PMI conference are very weak in this approach. But COS and the College of Performance Management (CPM) have much better quality papers and topics.

    So if you want a deep resource for scheduling, scheduling done in the way it should - MUST - be done, then start with Mosaic Project Services.

MIL-HDBK-881A No Longer Guidance

    MIL-HDBK-881A was classified as "guidance." Now it's Military Standard (MIL-STD-881 is the likely designator) with the related mandatory requirements.  Poorly formed WBS's (wib-us) as it is pronounced, are common in many domain of DoD. There are equally a number of good implementations of a WBS. 881A clearly and concisely states that the WBS is:

• The family tree results from systems engineering efforts during the acquisition of a defense materiel item.
• A WBS displays and defines the product(s) to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end product.
• A WBS can be expressed to any level of detail. However, the top three levels are the minimum recommended any program or contract needs for reporting purposes unless the items identified are high cost or high risk. Then, and only then, is it critical to define the product at a lower level of WBS detail.

To "foot and tie" this together, The EVM Contract Requirements Checklist has been updated read in part:

A product-oriented Work Breakdown Structure (WBS), in accordance with the DoD WBS Handbook (MIL-HDBK-881A) and the Contract Work Breakdown Structure (CWBS) DID (DID number DI-MGMT-81334C), is mandatory when EVM is implemented and a CPR and an IMS are required.  For contracts that require Contractor Cost Data Reports (CCDRs), the CWBS will be developed, approved, and maintained in accordance with DoD 5000.04-M-1, Cost and Software Data Reporting Manual, and the CWBS DID.

So Earned Value and WBS's go hand in hand. Measuring phsyical percent complete means measuring the physical progress of the product items being produced by the program. For more on this riviting topic, see the topical subjects at EVM World 2009, where yours truley will be speaking on "Earning Value of Earned Value."

Rediscovering how (some) A&D programs are managed

I love it when someone (re)discovers a concept. Such a concept is the Declaration of Interdependence for Modern Management at Alistair Cockburn's site. I'll paraphrase a bit from the middle narrative:

The DOI is a 12 step process, that can be seen in domains assumed to be waterfall, dinosaur-ish development domains...

1. Focus on value and watch the flow - IMP/IMS is a focus on increasing maturity of the products and services. Physical percent complete is measured against planned progress for cost, schedule, and technical performance. These three independent variables are inseparable and must be measured as one - the program performance measure.
2. Make the unit of value in the flow small - do weekly earned value, monthly Contract Performance Reporting, with Work Package that cross only one accounting period. This means they are usually 45 days long for a physically tangible deliverable.
3. Engage the customer in frequent interaction - the period is dependent on the size of the deliverable, but Technical Interchange Meetings (TIM) usually occur monthly, and access to the weekly Work Package peformance measures are through the Digital Environment for all to see.
4. Strive for shared ownership - this is a bit harder with DO-178 flight software, but most teams are "collectives" of subject matter experts holding each other accountable for a shared outcome.
5. Recognize that individuals are the ultimate source of value - if you're going to fly to the moon, you'll to retain the best of the best. It's all about people.
6. Create an environment where they can make a difference - how about flying to Mars?
7. Build/design/work incrementally - the weekly earned value assessments are a starting point, but Paul Solomon's Perfomance Based Earned Value (r) is the best guidance for anyone looking how to do difficult work incrementally.
8. Anticipate what you can - embedded risk management is mandated. This means risk retirement, Plan B, Plan C and continuous assessment of emerging blockages to progress as planned.
9. Use feedback - start with weekly EV and measures of physical percent complete within the parameters of Techncial Performance Measures.
10. Help everyone to feel shared responsibility for team effectiveness - what to see grown men (and women) cry? Go to the launch of the "baby" they've been working on for 5 years.

DOI, welcome to aerospace and defense IMP/IMS development as performed on mission critical programs

Modeling of Cost and Schedule

Alistair Cockburn referred to a paper posted in PMForum. (Along with Alistair's site, PMForum is a MUST subscribe site for anyone claiming to be a project manager) The paper suggests the causal source of the "fat tails" for distribution of work effort. This paper possibly provides a theoretical source of the practice of using the Triangle distribution for the source of Monte Carlo simulations.
    But several issues need to be addressed:

• The notion of infinite tails is not statistically sound. In practice triangle distributions represent bounded values for durations.
• The notion of infinite tails is not managerially sound. Models of duration and cost have management limits. In most cases these set at 125% of the baseline. After 125% overrun management intervention takes place and a new baseline established. In federal contracts Nunn McCurdy in breach is invoked. (There are numerous examples of this not being the case in commercial projects, but that's just BAD management).
• The notion of Linear Work is not used in any credible cost and scheduling model. The approach here in aerospace and defense is to bound the Work Packages with not cross more than one accounting period - usually 45 days. The allows the modeling of the Triangle distribution to be applied to a "not to exceed" duration within the two months around a single accounting period. This way the linear aspects are "forced" while the non-linear aspects are applied at a higher level. This does not prevent non-linear behavior but the lowest level is "linearized" and the macro level become tractable.
• Figure 2 of the paper is the most useful for our work. Modeling the difficulty of the work with the effort needed for that work is a Systems Engineering problem. Typically historical data is used. NASA has a extensive data base for "calibrating" work effort versus the technology. The issue of course comes when new work is needed - "inventing new physics" type work.
• The Stochastic behavior of humans is an interesting approach. The Monte Carlo simulations are driven by Probability Distribution Functions - Triangle is best used in the absence of underlying information. But true stochastic behaviors seem a bit extreme. Stochastic process are "true" random processes without correlation functions between internal variables and especially external coupling that evolve with time. This is unlikely in practice, but would make a great research topic if the historical data could be captured. But this paper is about the theory, so not an issue at this point. The author considers the task size, productivity, and task difficulty. A good starting point for this topic is Introduction to Stochastic Processes, Lawler, Chapman Hall, 1995. I actually looked at it a few months ago when dusting the bookshelf.

Here's a graph we use to show the coupling of input variances to output variances for a single random variable. Random processes are assumed to be stationary and therefore not stochastic.

    The challenge here is the define the coupling between work, productivity and difficulty. The paper does not speak directly to that. And unfortunately that is what is needed for any credible planning process. At the moment that information comes from subject matter experts.
    On the cost side there is similar "coupling" models used on the programs we work. This picture is taken from a training presentation provided by MCR Corporation - a thought leader in this subject area - cost, schedule, and technical difficulty modeling.

    My final - and constant - difficulty with the paper is the weak reference section. There is a wealth of material at the Association for the Advancement of Cost Engineering, INCOSE's Systems Engineering Journal, NASA's Cost Estimating Handbook site, and other "internal" cost and schedule modeling sites. The paper had two references.
    The paper is a "must read," if only to start the conversation about the probabilistic nature of Cost, Schedule and Technical Performance Measures in the presence of probabilistic risk models.

A Program Manager's View of AIG

    In the application of Earned Value of programs, there is a value below which we move on when trying to get all the control accounts to balance for the period of performance. Usually if you can get all the numbers to line up for 99% of the total value, its called DONE and let's print the Contract Performance Report (CPR) and send it to the customer. 1% error depended of course on the size of the program. There are time when 5% error is acceptable. And other times when less than 1% is needed.
    But to spend time futzing around with 1/1000 of 1% is not only a silly it is a waste of time. So why is the US Congress burning huge amounts of time and money on 1/1000 of 1% they gave AIG? Mostly likely to cover their asses for not having language in the bailout bill in the first place. Probably because those sitting behind those desks have actually never really managed anything. Nor would we want then to. No because they shoudl not, but because they are representatives of the people and should be focused on doing the people's business. Making Laws, no micro managing what is clearly a bone head decision by AIG.
    National politics is all about image and sometimes about substance. So getting your face on TV is part of image. If someone would go on TV and state in clear and concise terms that spending time managing the clearly poor decision of AIG's imbattled president is a wast of time, then maybe we poor souls here in the field woudl have some convidence things will improve.
    Indepedent of one's politics, we're loosing sight of good program management practices - focus on the big picture in times of crisis.

Planning

A friend provided a definition of Planning several years ago, that I've reused many times when the  question of Planning and Scheduling comes up. Mike Dwyer introduced me to this concept...

Planning is the ongoing dynamic activity of peering into the future for indications of where a solution may emerge and treats the plan as a complex situation, adapting to an emerging solution.

The schedule is the sequence of work activities that implements the Plan.

Deliverables are what the customer bought

    Shawn Kelly posted a comment on the Deliverables Based Planning^sm topic stating he has experienced difficulty in the IT domain with getting engineers to speak in a "deliverable" language. Shawn mentions some responses are:

• Trust me its done. How dare you ask!
• I don't have time for documentation
• Sure I can document that, what don't you want me to do so I can get that done?

These are responses from immature development staff. I say immature for one reason.

The customer has paid good money for a product or service. If the documentation is part of that product or service, they are expecting it to be delivered as well.

    Now the discussion of which documentation, how much, its contents and all that needs to be part of the planning process. Documents are just like any other deliverable. But here's the critical success factor for IT projects.

What are the deliverables produced in exchange for the money paid?

This is what the customer is expecting from the efforts of the developers. If they can't say when they will be done, then the customer can not recognize when "value" has been produced in exchange of this money. This is a "time cost of money" issue in every business on the planet.
    No matter what the project, the customer needs to recognize progress in some unit of measure that is meaningful to them. Money is a good measure of Meaningfulness. "You mowed my lawn, I gave you $20, we're even." When the agile proponents speak of "value" they usually mean "business value." The absolute best measure of business value is money. This is because they - the customer - gave you the developer "money." They want their money back at some time - return on investment. If someone says otherwise, they are not in business. They may be in something else - charity maybe. But even then charity takes money. And usually the benefits are measured in some form of money - health, welfare, education, etc. Not to say there are not all kinds of manager out there disconnected from the notion of ROI. But in the end, the amount of money a company has is limited and someone, somewhere in the company wants to know where the money went and when are we getting it back. This by the way is not the model for government, since they can print money.
    So for the question asked by Shawn, the answer should be:

Did the customer order that and provide money, then she wants to know when you'll have that ready for use.Be it a feature, a document, a product, or a service.

Now for some answers to Shawn's other questions

1. Are the responses above common to “true” engineering disciplines (systems, civil, electrical, etc.)? No software alone seems to not understand - in some environments - the notion of a contract. In fact agile suggests contracts are undesirable. But a contract - a promise to deliver something in exchange for something else - is a wonderful way to have "agreement" on what those things are. Contracts have a double edged behavior. Done right they focus attention on the delivery of value. "I promise to Love and Cherish you in sickness and in health," for example. They can also be misused. It's now the contract that is the problem, it's the wording in the contract. So the first step is to realize other engineering disciples know how to do this.
2. What techniques can be suggested to overcome this type of resistance? Focus on outcomes, actionable outcomes, beneficial outcomes. Do not focus on efforts or duration - at least in the beginning. What does done look like? My colleague Martin Radley reminds me What does done done look like? Meaning what does the customer say is done? If you start there, the conversation can be guided in terms meanigful to the customer. In the end it's all about the customer. Don't let those pesky software developers think otherwise. It's not about them.
3. Am I expecting too much out of the IT culture and do I need to adjust my own expectations? In some way yes. Maninly becasue of the culture of software. Robert Glass asked "Why is Software Hard?" in 2003. The answers were around the discipline of software development. Discipline does not mean heavy process. XP is highly disciplined, probably the most disciplned of the agile techniques. In the absence of discipline bad things happen. Be it software development, down hill skiing, or driving to work. I'd start from the customer side of the discussion. Many IT organizations we work with look at the world through their eyes , not the customers. When you invert that vision, and ask "what do our customers want us to do for them, how will they recognize our work as valuable, what are the units of measure that are meaningful to them?" then you're on your way to solving the core problem of IT - "making themselves useful to someone outside themselves."

Nothing New Under the Sun

    The GAO (Government Accountability Office) has recently published papers on the difficulties agencies are having in managing their programs.
    There is nothing new under the sun. Read Controls Over Consulting- Service Contracts At Federal Agencies Need Tightening, dated 20 March 1980. Depressing isn't the word for it.

Planning is NOT Scheduling

    A post on Paul Rasmussen's Blog describes how to "Plan for Success." The listed items are all necessary for success, but they may not be sufficient for success.
    The Plan is a Strategy for the Success of the Project. This strategy for success starts with a description of the Mission. The Mission has specific Goals and these Goals have specific Operational Outcomes. These Operational Outcomes have units of measure meaningful to the customer or stakeholders that are recognizable by them when they appear as a result of the work efforts of the project. These Operational Outcomes are usually described in a Concept of Operations or ConOps. An example ConOps can be found here or here (but you'll need to click through the cert questions). For major IT projects here's some guidance for developing a ConOps.
    In the absence of these elements the activities described in Paul's approach have not "home," no basis of measurement. Only after creating a PLAN can the items mentioned in the post be developed. Otherwise the questions to Why cannot be answered.

With the ConOps in hand, the Paul's item now has purpose.
See the concepts of Deliverables Based Planning^sm for some background.

16 Critical Software Practices

The Software Program Managers Network has a nice site with 16 Critical Software Practices useful to anyone in the software development business. The details behind them can be found at "16 Critical Software Practices."

NASA PM Challenge 2009 Presentations Available

NASA's PM Challenge 2009 presentation are now available. This annual event provides some useful information, some restating of the obvious, and some blatant advertising of professional services by consulting companies.
A few of my favorites presentations include:

• Developing & Validating a Center Earned Value Management System
• NASA’s New Risk Management Paradigm
• Integrating Risk and Knowledge Management: Lessons Learned
• Establishing an Enterprise Earned Value Management Capability
• NASA External Cost/Schedule Performance Reporting

Risk Management and Project Principles and Practices

Paul made a comment regarding the role of risk management for the previous post. The topic of risk management has many points of view:

• PMBOK(r) Chapter 11
• DoD PMBOK(r) Chapter 11
• DoD Risk Management
• David Hillson's approach described in his several books, Effective Opportunity Management for Projects, being a recent one
• Edmund Conrow's approach described in Effective Risk Management, AIAA Press
• SEI Continuous Risk Management
• INSEADS paradigm of four views of managing in the presence of risk
• NASA's Risk Management paradigm
• US Department of Energy's risk management paradigm
• MOASIC (Mission-Oriented Success Analysis and Improvement Criteria)
• Tools like Active Risk Manager and Ares's risk tool as well a Mitre's risk tools and paradigm

I've applied, used, or been involved in the application of each of these paradigms. Personally I'd not recommend PMBOK, instead read DoD PMBOK as a start. Depending in the domain and context any one of these - other than PMBOK(r) Chapter 11 - could be applied.
    But, and this is a very big but, risk management is not in the same league of an individual process area or a practice. It is separate and at the same time all encompassing. Those doing this best are working in the space flight business. There the role of Safety and Mission Assurance (S&MA) guides he risk processes. This includes:

• Identification and management of the risks and their handling.
• The Program Planning and Controls staff "owns" the role of programmatic risks and integrates these risks in the Integrated Master Schedule
• The Systems Engineering staff "owns" the role for technical risk in terms of impacts on the system
• The Technical staff "owns" the role of mitigating or retiring - retiring being preferred - for their individual disciplines. The SE's for the system as a whole.

Here's a very simple view of the interconnections of cost, schedule, and technical perfomance with the risk activities between the three.

In the absence of a 3 day workshop and a specific context and domain, this picture shocul be considered "notional."
    While risk is considered along with cost, schedule (not time), and Technical Performance, it is also an over arching process. A Systems process. But this diagram speaks to the artifacts of the risk management practice - cost, schedule, and technical performance margins. In the NASA approach and other DoD views, risks are defined as possibilities and need mitigations or retirement plans that impact cost, schedule, and technical performance.
    But this narrow band channel of a blog limits discussion around this important topic. Suffice it to say the PMBOK approach is not the starting point. Instead I'd recommend the SEI Continuous Risk Management book. But that is just a process maturity assessment outcome guide - with descriptions of what a good risk management process looks like. Conrow's work is the seminal approach for domains I work in. There are a multitude of dimensions to risk management, so a single paradigm will rarely cover what is needed in practice.

There may be other works in other domains.

Deliverables Based Planning™

The Deliverables Based Planning™ method is being deployed in several business domains. Ranging from traditional enterprise IT projects to space and defense programs with full Earned Value management processes

These four process areas represent a sequence of activities that increase the maturity of the programmatic aspects of a project or program. They need to be performed in order – at least at the macro level – to allow for this increasing maturity to emerge. For example, before we can start on the development of a Requirements Baseline, some understanding of the Business Need must be in place. Before we can start with the Performance Measurement Baseline (the cost, schedule, and resource allocation plan), we'll need to understand something about the requirements. And of course before we can start executing the project, we need a schedule, cost estimate, and some notion of the staffing plan.

Throughout these process, a Risk Management process is needed to identify and plan the mitigation or retirement of project risk.The individual activities at each level start with:

You can click on the image to get the bigger picture.

This method is Copyrighted material of Lewis & Fowler (my employer) but is presented here as an illustration of where the project and program management community is headed in the "mission critical" world, where deliverables are the focus of discussion.

    Underneath these top level processes are 3 more layers of activities. This approach is indepedent of any engineering or technical solution approach - meaning everything from formal DO-178B development processes, to RUP, to Scrum and similar agile software development can be applied during the "Execute the Performance Measurement Baseline" activities.

    Two distinct domains are currently using DBP™. One using a customized RUP in a large telecommunications firm and another in a defense software and hardware domain.

    The message is "project management processes" are indepednent fropm software development processes.

Cost Estimating and Assessment

    Thanks to Paul Solomon for notifying all of us on his mail list that the final release of the GAO Cost Estimating and Assessment Guide is out. While many in the project management domain may view this 438 page guide as completely over the top, it is in fact a seminal source for good project management practices in the areas of cost, schedule, technical performance measures and programmatic risk.
    In FY (Fiscal Year) 2008, the federal government spend $412 Billion on it products, services, and other expenditures. The monthly details- the Federal Balance Sheet - shows the distribution of these funds along with the income.
    Here's the point. Learning how to manage the cost, schedule, and technical performance aspects of a project or program - any project or program - is critical to its success. The development of technical products - either in the context of a full CMMI Maturity Level 5 Technical Solution (TS) and all the accompanying Process Areas scattered around the globe, or two guys sitting in the same room with their customer banging out C# code. And all the instances in between these two extremes. In all cases - even  if it's your own money - someone, somehow, in someway - you need to know the following:

• How much is this going to cost when we're done?
• When will we be done?
• What are we going to get of value - business value - when we're done?
• What are the impediments to getting done?

The answers to these questions probably shoudl not emerge from the primordial swamp water. Some kind of estimate up front is needed. Event a "guess" is better than nothing.
    So take a look at this tome. It's insight into the processes used by those accountable for the $412 Billion, or at least those subject tot he Federal Acquisition Regulation (FAR) when they are spending our money. For those of us working in that domain as well as the enterprise IT domain, where the numbers are a bit smaller, but not that smaller on an individual basis (it's not uncommon to spend $100M on an ERP system in a large corporation). This guide book has some things to say about some important aspects of "managing projects," not just writing code in your favorite agile method:

• Measuring techncial performance (is the product on track to meet its technical, operational, and business requiremenst) in terms of qualtiy along with the cost and schedule metrics
• How is schedule and cost data correlated with this techncial performance measure?

S = k log W

    The work you have in the current period of performance, the higher the entropy of the project. Adjust the work load to match the energy available to mange that work load. This means there must be sufficient cost and schedule margin to absorb the variations in the work process. This means the "capacity for work" must be known to some level of confidence before starting the current period of performance.
    The period of performance can be an iteration, a rolling wave, a print, or any bounded period of time in which ALL the planned deliverables are delivered.
    Boltzmann aid it already...

S = k log W
Entropy = (an adjustment constant) * log of the Work