Thank you for attending this session today. I know there is lots of competition for your time and attention. My name is Glen Alleman and I’m a Practice Vice President for the Aerospace and Defense offerings of Lewis &name is Glen Alleman and I m a Practice Vice President for the Aerospace and Defense offerings of Lewis & Fowler, in Denver Colorado.What you will learn today will allow you to go back to your company and change the way you think about projects. Not because of tools, because this session is not about tools. Not because of some magic formula for running your project, because there isn’t one. But because you’ll have a different view of how projects are structured and different words to use when talking about how you run your projects. The first set of words are “The Probability of Success.”Let me finish my opening here with a bit about myself. My primary interests these days is the application of Program Planning and Controls (PP&C) in the aerospace and defense business. What this means of management of the cost schedule and technical performance measures of complex technology programsmanagement of the cost, schedule, and technical performance measures of complex technology programs using Microsoft tools integrated in a distributed teaming environment.I’ve been a program manager in aerospace and defense, deputy CIO in a Department of Energy weapons plant decommissioning project, a program planner, a proposal writer on a variety of programs ranging from aircraft flight controls to manned spaceflight systems.My formal training is in particle physics, where I wrote software digital filters to process the data stream from an accelerator. That turned into digital filters for radar, sonar, and guidance systems. Then into managing those types of programs. With a stint in the commercial side, I returned to A&D. Eventually I moved into the consulting business, where we now provide PP&C, IT project management, process improvement, and strategic planning services to both commercial and A&D clients. Between doing engineering and managing engineers Iplanning services to both commercial and A&D clients. Between doing engineering and managing engineers I was sent back to school to get a Masters in Systems Management – blend of Systems Engineering and Finance.

1

This may be a new concept, this is the phrase Probability of Project Success (PoPS). Y th t ll j t f l b t ll k th t’ t thYou may assume that all projects are successful, but we all know that’s not the case.There are many reports about troubled projects. In fact some firms make their living by reporting how bad projects are. It is assumed then that your project will be troubled as well.But let’s invert that notion and look at project management from another point of view.How do we increase the probability of success of our project? We’ve been told our project is not doing well, but how can we improve?There are several important words here:

Increase – make better.b bili h i i l h h hi illProbability – the statistical chance that something will occur.

Success – the beneficial outcome of some kind of effort.So if we want to increase the probability of our project’s success what do we have to do?But there’s one word that keeps recurring – DONE.It’s really DONE that we’re after. That’s what the customer bought, that what the customer wants to happen from your project.

2

So first let’s review what is a project.It’ ff t It’ t ti It’ t t bl lth h th th tIt’s a one off event. It’s not operations. It’s not repeatable processes – although the processes that manage projects is repeatable, the project itself is a one time occurrence.I’m telling you this just to make sure we don’t get confused between finite, one off work and the continuous work of operations once the project has produced its product or service.The reason this is important is that projects are a “one chance to get it right” type of endeavor. Operations has several chances to get it right. Maybe a lot of chances. Sometimes only a few. But never just one.That’s why we’re here today. To learn a bit about increasing our probability of success in the “get it right the first time,” world of projects.Now there is another word here – probabilityNow there is another word here probabilityProjects have a probability of success. There is no guarantee. We’d like this probability to be as high as possible. For some projects the probability is high – close to 100%. For some projects the probability, while acceptable is actually low. There is 1 chance in 149 of losing the mission for the Orion Manned Spaceflight program with specific types of launch vehicles.What’s the probability of having your Enterprise ERP project rollout fail in a way that causes an unrecoverable loose to your company? Good question.How can you improve the probability of success for your project? Another good question.We’ll get to the answers to these questions during this presentation. In the end you’ll be able to answer your own questions in my absence.

3

We’ve all seen the numbers.W ’ ll b t ld h b d thiWe’ve all been told how bad things are.77% are due to poor planning or poor project management.Here’s one more look.But we’re here to work on only one aspects of the “money flushing” business of Enterprise IT or what ever high risk business you’re in.We’re here today to talk about the project management aspects of projects. The planning, scheduling, costing, management verbs of projects.These are called the Programmatic Elements of the project. Versus the technological aspects.As a program manager I’m very interesting in the technology. But my job is to make sure the programmatic aspects work, so the technology has a chance of actually showing up on time.

4

Here’s our first actual learning opportunity.Th th fi l t d d t i th b bilit f f j tThese are the five elements needed to increase the probability of success for your project.When you read these you’ll all agree they are obvious. We know the definition of all these words.All the words have been said before. We’ve pretty much “been there done that.” Well maybe. Maybe there some subtleties here.But for the moment, let’s pretend that we know these words, but our problem is how to put them to work.How to make these words and the phrases they construct – ACTIONABLE.Actionable is a good word in project management. Because if it’s not actionable it’s not that useful.g p j gSo let’s get started on the first step toward ACTIONABLE OUTCOMES that increase the probability of project success (PoPS).

5

The first step in increasing the probability of success is to start with discovering what capabilities we need from the project Capabilities may be new to some of you in the project management business A Capability is anthe project. Capabilities may be new to some of you in the project management business. A Capability is an ability to do something of value for the enterprise. It’s not a requirement exactly – but requirements come from Capabilities.

Think of a capability in this way. If what I want was free, showed up Monday and worked in exactly the way the brochure said it did – what would I do with it.

Here’s some words closer to home.

We need to pre-process insurance claims at $0.07 per transaction rather than the current $0.11 per transactiontransaction.We need to remove 1½ hours out of the retail ordering process once the merger is complete.We need to change the wide field camera and the internal nickel hydride batteries, while doing no harm to the telescope.We need to fly 4 astronauts to the international space station, dock, stay 6 months, and return safely.We need to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and guidance capabilities in the existing touch panels.We need to integrate two customer facing inventory control systems within 2 months of our merger.

6

From capabilities we can derive requirements. Requirements are the glue that holds the project together. You’d think is was the schedule the plan the budget But not truethink is was the schedule, the plan, the budget. But not true.

Poorly managing requirements is the major contributor to project failure. Increasing the probability of success for your project means getting your arms around requirements and the management of those requirements.

But before we get too far into this, let’s ask what is a requirement? Here’s a formal definition. Formal definitions are good, since they don't provide much wiggle room for people to wiggle out of actually stating what the requirements are.

A Requirement is …”A statement identifying a capability, a physical characteristic, or a quality factor that bounds a product or process need for which a solution will be pursued.”

— IEEE Standard 1220–1994

Now this may not be that useful for your project, but it’s a start. Let’s seen where this definition can take us.Notice this definition uses the word “capability.” this definition was created before the Capabilities Based Planning paradigm was developed.So let’s stop here and ask “how many people believe they have good requirements for the current project they are working on?”

7

With our requirements defined, we can start to develop a Plan. But this Plan is not a schedule – yet. the Plan is the strategy for our success It is the strategy for getting to “Done ”the strategy for our success. It is the strategy for getting to Done.

The Plan is a strategy to successfully complete the project, described as the significant accomplishments and their accomplishment criteria.The Schedule is the sequence and duration of work needed to implement the plan.The Schedule (the activities that complete the Accomplishment Criteria) is derived from the Plan (the flow the Significant Accomplishments).

With this definition, how many people here today would say they have a Plan in addition to their Schedule?

8

Now let’s put all this together.St ti ith th WBS th t i l d t d i j t ith W k P kStarting with the WBS, the terminal nodes are represented in project with Work Packages.You cannot have a project without some form of a Work Breakdown Structure (WBS). Building a good WBS is a day long workshop all in itself.So how many here have a Work Breakdown Structure for their project? This may not be a term you’ve heard of before. A Work Package is a lump of work that produces a single outcome. A “package of work” that produces something.For the schedule putting the Work Packages in the proper order is the starting point for a credible schedule. If you can get the Work Packages in the right order, with their durations defined, then you have the start of the credible schedule.credible schedule.The next step is to not do nay more scheduling in MSFT project. Instead let the Work Package manager look have the activities inside the Work Package and be done with it.This is how large Defense and Space programs schedule. There are three levels of schedules mandated by a government “rule,” DID 81650.For the commercial side there is no mandated regulation. But 881A and the PMI Work Breakdown Structure Guide are the best places to start.The Master schedule – a top level “picture” what is happening in what order.The Intermediate Schedule – the sequence of Work Packages.q gThe Detailed Schedule – the day to day activities of the project.For IT projects, the Intermediate schedule is a sweet spot. One that connects cost with work and deliverables. One that minimally imposes effort on the team and fits well with the agile world of Corporate IT software development.Since agile is focused on defining deliverables and measuring progress through working software, it is a natural fit for a WBS.

9

There are several risk management paradigms. This one belongs to the Software Engineering Institute. The Continuous Risk Management (CRM) processContinuous Risk Management (CRM) process.Another paradigm is the Department of Defense Risk Management Guidebook. These two approaches provide essentially the same framework. One place is the Project Management Institute's Guide to the Project Management Body of Knowledge®. I’d recommend the SEI CRM for its completeness.But along the way remember there are five easy pieces of risk management.1. Hope is not a strategy. Only actionable outcomes can be the measure of risk handling2. All measures are random variables. You must know the underlying statistics and variances of those statistics

to have any meaningful discussion of riskto have any meaningful discussion of risk3. Never forget cost, schedule, and technical performance are inseparable. Change one, the others change

too, in some way.4. You have to follow a known risk management process. SEI is good, so is the DoD process. PMI is OK. PMI’s

better than nothing5. If no one knows your looking after the risks, than you’re wasting your time. Communicate risks!!

10

Let’s revisit where we’ve come from.W h fi th t d t i b bilit fWe have five process areas that we need to increase our probability of success.1. Identify the needed business capabilities.2. Identify the technical and operational requirements that cause those capabilities to appear.3. Build a Plan and a Schedule to implement those requirements.4. Execute that Plan and Schedule.5. Continuously manage the risk of the project.With these concepts in mind let’s look at how we can actually do this.

11

Having knowledge of something is critical to actually putting that knowledge to work.B t t i t d k ith t h i th d l i k l d t “ k ”But trying to do work without having the underlying knowledge creates “rework.”Let’s put what we’ve learned so far to work at the next level through some examples from “real” projects.

12

Here’s a picture of actual output a capabilities development session for a major ERP system integration programprogram.Starting in the upper left, the needed capabilities are captured through a Product Development Kaizen with the stakeholders in an offsite session. These Kaizens are full contact meetings where the participants work “on the wall” to reveal the capabilities and the attributes of these capabilities.These sticky notes are then captured in some organizing tool. My favorite for this level of detail is MindJet’s Mind Manager. It is a hierarchical organizing tool that can export its structure to MSFT Project.No matter what tool you use, you’ve got to have some way to “discover” the business capabilities before moving the next stage of the project.Without a clear and concise description of the needed capabilities you’ll have a hard time recognizing “Done” when it arrives – if it ever arrives.We’ve all heard of, or possibly used a system that met all the requirements but failed to provide the business value that was promised. The development of the Capabilities – preferably in a Concept of Operations document is the foundation for the remaining efforts in increasing the probability of success for your project.With the Capabilities in hand, the technical and operational requirements become clear – or at least clearer.

13

The first step is to separate “product” requirements from “process” requirements. The product could be a service as well but the product (or service) is not the same as the process that delivers the service that may be enabledas well, but the product (or service) is not the same as the process that delivers the service that may be enabled by the product.We can see there are several components of this separation. Later on in this session we’ll put this taxonomy to use with a process for requirements management. While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our efforts on important the parts of requirements management, and reduce the overall effort of managing these requirements.We‘ need to separate the requirements into process requirements and the product requirements. As well we need to have BOTH classes of requirements.Process Requirements without Product Requirements have not way to implement the processes.Product Requirements without Process Requirements have to business value generation opportunities.Many IT project start with the Product Requirements and then try to figure out how to put this product to work. “Let’s install a portfolio management system.” “Let’s buy Project Server to manage our collection of projects.”Statement like these are Product Requirement centric. While not a totally bad idea, most project failures can be connected to missing process requirements. Even if the product requirements have been fulfilled.The inverse is not as much of a problem. With a well defined set of processes, the products needed enable those processes can be acquired over time.

14

Current Requirements – Requirements that have been properly identified and implemented by some prior project These represent the current capability of the enterpriseproject. These represent the current capability of the enterprise.Unknown Requirements – Requirements that need to be met under the current business case, but that are unknown or hidden from the organization. Requirements analysis seeks to discover these requirements.Discovered Requirements – Requirements that have been discovered but that have not yet undergone the scrutiny of management and organizational review. These represent the options available to the organization, and many may even conflict with each other. Requirements analysis seeks to sort these out and determine which from among the many options the organization actually desires.Desired Requirements – Known requirements that the organization has determined a desire to see implemented. Selecting to desire some requirements necessarily precludes desiring requirements that represent other conflicting possibilities Requirements analysis seeks to assure that desired requirements arerepresent other conflicting possibilities. Requirements analysis seeks to assure that desired requirements are feasible; otherwise further consideration must be given to less–desired options.Feasible Requirements – Desired requirements that have been determined to be technically feasible, meaning that they can be implemented using existing known technologies, tools, and methods.Possible Requirements – Feasible requirements that have been determined to be organizationally possible; meaning that they satisfy enough political, budgetary, and resource concerns to be allocated to a project.Allocated Requirements – Requirements that have been allocated to a project for implementation.

15Copyright © 2008, Lewis & Fowler, 8310 South Valley Highway, Englewood CO80112www.lewisandfowler.com

Putting all this information into a framework is next. Thi f k i f b t it’ i l d f l f t d d th f t dThis framework is one of many, but it’s simple, and even useful for our current needs and the future needs as well. This framework does several things:1. It asks 5 of the 6 question in Rudyard Kipling “Six Honest Serving Men” from “The Elephants Child.” “Where”

is missing, but know where – we are at the business where we are gathering requirements for our systems.2. It demonstrates the layering of the requirements and their evolutionary nature.3. It shows some of the techniques for managing these requirements.

16Copyright © 2008, Lewis & Fowler, 8310 South Valley Highway, Englewood CO80112www.lewisandfowler.com

When we talk about “the customer” along with all the other sources of requirements, it’s important to know what exactly the role of the customer iswhat exactly the role of the customer is.This role is limited. Not limited because we don’t want to know what the customer wants. It’s limited because the customer can provide only a limited amount of requirements information. Here’s some of the things a customer can provide

17

Here’s a real example of a master plan and the master schedule that goes with it.Th Pl i t t t f ll l t th j t d ib d th i ifi t li h t dThe Plan is a strategy to successfully complete the project, described as the significant accomplishments and their accomplishment criteria.The Schedule is the sequence and duration of work needed to implement the plan.The Schedule (the activities that complete the Accomplishment Criteria) is derived from the Plan (the flow the Significant Accomplishments)This is a “real” Integrated Master Schedule, complete with the Integrated Master Plan. Each Accomplishment Criteria represents the “exit criteria” for a Work Package. The completion of the Work Packages provide the needed completion of the Significant Accomplishments.

S f fThese Significant Accomplishments are the entry criteria for the Program Events, where the planned maturity of the programs deliverables are assessed.

An example of a Significant Accomplishment would be “Initial Database Design and Sizing Complete”An example of an Accomplishment Criteria would be “Initial legacy user list captured”The Accomplishment Criteria is the EXIT criteria for a Package of Work needed to capture all the legacy user data. The Significant Accomplishment represents a 100% DONE outcome that can be put to work in some way. Either in actual use or as the basis for a higher level deliverable.

18

Program Management and the Program Management Office must “earn their keep.” Thi t k l th h 4 l itiThis takes place through 4 value propositions1. Management of Cost, Schedule, and Technical Performance at the individual project level is the

responsibility of the Project Manager. When individual projects are collected into a Program, these measures of performance become the responsibility of the Program Manager and the Program Management Office.

2. The tools needed to assure project and program performance come from the Program Management Office. The processes needed to successfully deploy these tools and their benefits are the responsibility of the Program Management Office.

3. The Program Management Office and Program Managers can normalize the information flow between the business stakeholders and the individual projects. The traditional asymmetric exchange of information is replaced with standardized performance measures making visible cost, schedule, and the technical performance of projects and their programs.

4. Monitoring and oversight of cost, schedule, and technical performance and the resources needed to produce the needed compliance for the project’s and program’s success

19

When we speak about increasing maturity, evolutionary development and measures of physical percent complete – one good way to visualize this is through a product maturity flow diagramcomplete – one good way to visualize this is through a product maturity flow diagram.This diagram is a “real” one from a claims processing ERP system rollout, complete with COTS (Commercial Off The Shelf) integration with legacy systems and custom software development. The worse of both worlds.The critical success factor here is the define upfront what “done” looks like for all the incremental business value elements of the program.Each of the circles is a point of maturity, where the delivered product or service can be put to use in some way.As well the project can be canceled at each of these and the investment put to work. Many people would be unhappy, but the financial aspects of the program would remain intact.This type of diagram also shows the dependencies between the down stream (right) and up stream (left)This type of diagram also shows the dependencies between the down stream (right) and up stream (left) elements of the project. What has to come first, before business value can be delivered.In other domains (defense and government) these diagrams are built during the Product Development Kaizen process to show what must be done to get to “done.”

20

Here is a simplified Risk Management process. Th t f i k i h d lt j tThe management of risk is how adults manage projects. Risk management is a continuous process taking place during every phase of a project.

21

So let’s connect our 5 process areas with the three attributes of any project. H ’ ti l i t f th tiHere’s a notional picture of these connections.The term notional means a picture that “could” the real way to do something, but it is not actually the way it is done in practice.In other words it’s a nice power point slide of what might take place. But there’s more to it than what’s shown in the power point slide.Since we talked only about the “processes” in this session, this leaves the people and tools unaddressed.With the processes you can buy tools.With the processes you can find good people to implement them.

h j h i h h i i h b bili f f h jIt’s the project management process that is the anchor to increasing the probability of success for the project.

22

So here’s our final visit to the questions we need to answer to increase our probability of success.Wh t biliti d d? Thi i th “ h ” ti Wh d i thi j t ’ d i itWhat capabilities do we need? This is the “why” question. Why are we doing this project. we’re doing it because our business needs a new capability. We’re doing it because our nation wants to explore Mars. Without the answer to Why, we can easily get lost when something goes wrong on the project.With our capabilities defined, what are the technical and operational requirements that must be met. Answering this is straight forward of we follow the advice of the Requirements Engineering thought leaders.With this information we can build a credible schedule, measure our progress to plan, and remove any impediments to this progress

23

All these processes and their interactions we need to put all this into perspective.Whil t l d iti ll i t t h i th i ht l i th i ht “ t th b ” JiWhile tools and processes are critically important, having the right people in the right “seats on the bus” as Jim Collins would say in “Good to Great,” is as critical. These people must have a deep understanding of how to put the tools to work on their behave or the tools are of little value to the organization.We’ve seen this many times, where a program management or technical groups purchased a tool as the solution to their problems. Only to discover they did not understand the problem, so the tool had no chance of success.OK, this was nice, but what are some next steps.1. Ask and answer the five questions we’ve been speaking about for the last 60 minutes2. If there are no answers, find out how to get the answers. Without the answers, you can not really start to2. If there are no answers, find out how to get the answers. Without the answers, you can not really start to

improve the probability of success.

24