Herding Cats

It's August 1972

Alan Kay's 1972 paper "A Personal Computer for Children of All Ages," has come true in many ways. The paper shows childern looking at the Dynabook at a pitcure of a spacecraft.

There are several Google Nexus's ads where children are running through the house, with the space helemets on, looking at a picture of a spacecraft.

The future has now arrived. Still waiting to see if the Microsoft Surface is anything beyond an Ultrabook, without enough storage space - minumum 300GB for my needs.

End-to-End Delivery of Business Solutions

The delivery of "business solutions" depends on many things. But it starts with knowing and then producing the needed capabilities for success. Capabilities provide defined outcomes that are not a final conclusion, but the basis for continued assessment of value in terms the business understands.

There are several elements in the production of capabilities:

• Capability – The capacity to be used, treated, or developed for a specific purpose.
• Objective – Something worked toward or striven for; a goal. Objectives are entities that are reached and their strategic value delivered.
• Feature – A prominent or distinctive aspect, quality, or characteristic. Features and Functions describe the static and dynamic behaviors of the system, but are not easily connected to business strategy.
• Function – A procedure within an application.
• Milestone – An important event. Milestones indicate that a point in time has arrived or has passed.

Capabilities answer the question “in order to achieve of objectives, using features and functions at this milestone we must possess this capability.” It’s the capability the business wants, not the features, functions, met milestones.

Capabilities Based Planning

• Capabilities Based Planning is planning, under uncertainty, to provide capabilities suitable for a wide range of business challenges and circumstances, while working within an economic framework.
• Capabilities Based Planning emphasizes flexibility, adaptiveness and robust capabilities, implying a modular building–block approach to Enterprise Services.
• When transformation does take place it is because new capabilities have come into use.
• A capability is an ability to effect an outcome, react to an input, or change an effect. Before (features and functions):
  
  • The General Ledger will be installed and operable in all financial centers by fall of 2006.
  • After (Capability): Provide the Capability to acquire a $100M business in less than 90 days.
• A capability provides an outcome or effect without an a–priori specification of the outcome or effect.
• Features and functions require an a–priori specification in order to test for their existence or conformance to the specification

So here's an example of a needed capability and how it was provided by a larger telecommunications company.

The Higgs and its reason for being here

The question is why is there a Higgs Boson is commonly asked in our group of engineers and business neighbors. There are lots of good explanations. One is provided by the PhD Comics guys. Recently there was a question from an electrical engineer, what is the source of the Higgs field? Is it like the electromagnetic field, that comes from accelerating electrons? The force of the electromagnetic field is carried by the Photon, shown in the picture below.

No, The Higgs field and the Higgs Boson is a scalar field, where the Photon and the Gluons that hold the nucleus of atoms together are vector fields.

While searching in the upstairs library I came across a nice explanation that is beyond the cartoon versions - which BTW are very good at setting the stage - but without all the real math needed to connect the dots.

The Higgs is based on the assumption there is a scalar field, the Higgs Field, the permeates all of space. This field couples to particles, including massless particles to give them potential energy and of course according to the mass energy relation E = MC², a mass. The stronger the coupling, the more massive the particle.

From the very accessible book Concepts of Mass in Complementary Physics and Philosophy, Max Jammer

The way particles are thought to acquire mass is their interactions with the Higgs field is somewhat analogous to the way pieces of blotting paper absorb ink. In such an analogy the pieces of paper represent individual particles and the ink represents energy, or mass. Just as pieces of paper are different size and thickness soak up varying amounts of ink, different particles "soak up" varying amounts of energy or mass. The observed mass of a particle depends on the particle's "energy absorbing" ability, and on the strength of the Higgs field in space.

The Higgs process is not generated in the particle, it is only transferred to the particle from the Higgs field, which contained it in the form of energy. The store of energy can be thought of as a source of inertial mass, just as the inverse that inertial mass can be thought of as a store of energy.

In Jammer's book, the Higg's particle and the Higgs field had not been found, now it has. The next big question is why do specific particles have specific masses? What are the rules that say why specific particles weigh certain amounts? What are the rules governing these masses.

At the time of the Jammer book, the paper Inertia as a Zero-Point-Field Lorentz Force was the basis of the theory of mass that used the Higgs before it was discovered. BTW, the link here is to www.arXiv.org. This is a pre-print library, that used to be located at Los Alamos National Laboratory.

Here is most of everything you need to find out about current science topics, including the actual answers to my issue with the populist notions of complex adaptive systems - see the Nonlinear Sciences section near the bottom of the home page for Adaptive and Self-Organizing Systems.

Actual studies like "Opinions, Conflicts and Consensus: Modeling Social Dynamics in a Collective Environment" are an example. With this source, you can start your move beyond the populist approach found in the agile world that many time passes as tested advice, but of course is only opinion.

So, The discovery of the Higgs is just the beginning of a whole new search for answering Mach's question - why is there mass?

Trust

Steve Wake's presentation at IPM EVA, from Jack Ricchiuto's site.

• Weighted expectations - the relative importance of each expected outcome from the work effort.
• Delivery of Expectations - do those expected deliverables actually show up?
• Clarity of expectations - the mutual understanding of what "done" looks like in units of measure meaningful to the decision makers - on both side of the outcome - the provider and the consumer.
• Usefulness of feedback - with the shared outcomes and the shared accountability, was the feedback through out the processes that increased the probability of success.

The units of measure are fractional percentages of the idea - undefined of course - but an ordinal measures agreed to by the participants.

This approach to trust is much different than the personal trust commonly found in the project management soft skills presentations. This approach to trust is can I trust you to do what we agreed you would do, by having creating a mutual accountability for the shared outcome?

In simpler terms, as a member of the project team, can we count on you to do what is needed and what you agreed to do to increase the probability of success?

This is the inverse of those soft skills approaches. Members of the team start with the ability to produce value - increase probability of sucess - and then we can move to the personal interaction conversation. The soft skills approach leaves open the question can you get the job done? This approach starts with that answer and then moves can we built further on our personal relationship, now that everyone trusts you to get the job done.

This is harsher than the soft skills approach, but in the end the project recipient is really not that interested in much beyond getting the job done.

Stop Motivating People - They Hate It

A post on Curious Company had an interesting statement

Stop Motivating People They Hate It

This resonated with me for several reasons. Motivation comes from internal forces. Attempts to motivate externally - that is I'm trying to motivate you to do something - only works at certain ages and in certain situations. We were fortunate enough to discover Parenting with Love and Logic early enough to apply some of the processes to our two children when they were accepting of our efforts. The result has been good. Both are in college, both are graduating more or less on time,  one this May, one 1 year late since he added a dual major (Biochemistry and Cellular Biology, and then announced a Math Minor). But good kids and motivated to learn, share, grow, and play. I asked the Love and Logic guys if they were going to do a course for adults. The answer was it's too late, you have to get your kids on the right track, adults can't learn motivation in a way that is lasting. This by the way is why 97% of diets fail. A local riding group Phoenix Sports usues cycling as a recovery process, motivation seems to work there, but there are many external as well as internal motivators, not the least of which is to become a competent cyclist in an environment where pros share the road with amateurs.

In the business world I don't want to work with anyone who needs motivation. It's a waste of time, annoys the person and annoys me as to why I need to motivate someone I pay good money to do their job. But in reality it's a fact that some need motivation.

In the book Making the Impossible Possible, there is discussion around getting people to follow the leader and at the same time create their own solutions. This is called Positive Deviance. This may be the case of motivating, but it's in a different sense than getting people to do the right thing. PD is about as close to motivation as you should come in the business world.

In the Target Process site there is a quote let's try and do the best in the world at <something>. This can be applicable to anything actually, it doesn't have to be a fancy dancy agile project, er, software development management, tool. It can be regular work.

We just finished constructing and submitting the Contract Funds Status Report for one of our Army clients. A couple of 100 million dollars for funds had to be reconciled against the past work, the future work, the planned work, the spend rate, and the Management Reserve needed to delievr on-time, on-budget, and have the thing work as defined. This sounds like dreadful work to some. But for us it's not dreadful, it's quite exciting.

The past CFSR's were less than acceptable to the government, were not that great at forecasting the future need for money, and were pretty much lame. After 3 weeks of grueling work, with several 20 hour days, the team landed soft with a CSFR that is a thing of beauty. Every Control Account, every Work Package, every Activity foot and tied to the Contract Budget Base (the award value), tied off the the labor rating (how is charged for each person), the subcontractor contracts, commitments, and invoices, and all the other nitty aspects of  spending the governments money.

Our team worked hard, played hard, and had a sense of accomplishment, learning (more than wanted to sometimes), comradeship, shared suffering, and shared success.

But no one and I mean no one on the team needed motivating to get their job done on time and 100% correct (the federal government has no tolerance for sloppy work, since there are instructions). We had a mission. We had a vision of what DONE looked like. We each knew our role, the role of the others, the tools, the data, the process. Motivation processes will do nothing to increase the probability of success. Period, it's a waste of time. Get the right people, in the right jobs, get the wrong people off the project (off the bus as Jim Collins says), and have all the advisors, by-standers, those with opinions but not contributions - out of the room, out of the building.

We almost did what was suggested in the post

You should not track time, you should not estimate effort, you should not set deadlines. You should trust people, set ambitious goals and help them learn. We did that.

We had to track time and we had to have a deadline, because we had a due date and we had limited hours to do the work, so we had to have a plan of the week, then a plan of the day, and in the last 3 days a plan of the hour, if we were going to get the CSFR out the door on time and 100% correct.

So take care with the advice of others if they are not working EXACTLY in your domain and context, or their advice is not based on immutable principles. Use their ideas as just that, ideas. But always get the right mission, vision, people, processes, and tools, so no one needs any motivation.

Hume's Advice for Theoritical Business Process Advice

Hume has some advice for the proffers of business or process improvement that fail to provide tangible evidence from the field that such adbive actually works in a domain interesting the reader ...

If we take our hand to any volume - of divinity, or school metaphysics, for instance - let us ask: "Does it contain any abstract reasoning concerning quantity  of numbers?" No. "Does it contain any experimental reasoning concerning matter of fact and existence?" No. Commit it to the flames, for it can contain nothing but sophistry and illusion" And "The whole world presents nothing but the idea of a blind nature ... pouring forth from her lap, without discernment or parental care, her maimed and abortive children."

Show Me the Numbers!!

 

Is This Really True?

The notion that there is a need for a new management paradigm is a recurring theme, well documented in Beyond the Hype.

Here's a map of the conjectured causes and symptoms driving the need for transformation. Most are restating the obvious. I've looked at this picture from the Stoos Network site for some time. I've come to the conclusion there is a fundamental flaw in the process.

 

I know it says DRAFT, but these RCA (Root Cause Analysis) appear to be disconnected from the reality of business management:

• Public firms need to focus on shareholder value, otherwise there will be no shareholders, and there will be no firm for the shareholders to invest in. This is a fundamental principle of market economics. To suggest this is the starting point for improvement is not only uninformed it is foolish for the leaders and stockholders.
• I'd like to see the evidence that the C-Suite is incented to maintain the status quo in the publicly traded firm. Senior managers must react to changing market forces or they will not be senior managers of public firms for long. These responses may not be the right responses, but maintaining the status quo needs actual examples in some statistically significant numbers to claim this is a root cause.
• Mechanistic thinking may be present in some firms. I've worked in some.
• Unsuitable leadership model - seen this as well and worked there as well.
• Leadership skill missing in today's managers - yep common. If these skills weren't missing our services would not be needed. And since they are in large quantities, it appears leadership is still missing.

By the way, this notion of anecdotal experiences as being the source root cause analysis is troubling to me as a process improvement performance. When a group is attempting to syndicate their suggestions to others, it is best to have a clearly defined paradigm, domain, and context in that domain identified before hand, so those submitting ideas have a place to park those ideas. Otherwise, it's just a list of anecdotes - fine for cocktail parties, but it's STOOS trying the Change the World?

This seems common in the agile community for some reason. Maybe because they didn't take the High School statistics class, I don't know. But when a group of formed to change the world, it might be useful to understand the notion of sampling, inference, causality, and correlation. Especially when RCA is being mentioned, to have a look at how 6sigma and RCA is used in practice.

In the end - the far right - the statement shareholders and workers and customers are ALL doing poorly - is one of those blather statements that presents no valid evidence for how many, in what industries, of what size, in what nations, for how long, and what are the consequences? Again a possible failure of the public school system ;>)

Pearl Tree

I've used several approaches to collecting and managing ideas over the years. There were URL browsing capture tools that put links into folders. There is of course each browsers ways of saving links. There is MindJet which can do this on your computer and then you can publish the Mind Map to the web. The are several mind mapping tools, The Brain is one that I tried for awhile.

But now I've found what I was looking for, with a few missing features. It's call PeralTree. Not that snappy a title. But it does what I need. Captures web content and arranges it into "trees" that can be navigated with a Flash PlugIn. You can share nodes in the tree with others.

It needs some more work.

• Interface with Outlook for emailing links to locations in the Tree
• A way to cross link, so navigation can move between nodes. That would make it a network navigator

But so far it fits the bill for the perfect idea organizer.

Quote of the Day - Good Leaders Are Rare

I found this not only motivating, but guidance for everyday life as well.

From Robin Greenspan's news letter via ExecuNet.

Quote of the Day

“Nobody wants to buy sour milk.”

- Tim Cook, new CEO of Apple, when asked why spending is high on supply chain and manufacturing at Apple.

When we talk about optimizing the throughput of product development, nobody seems to do it better than Apple. In the book Competing Against Time,  about using supply chains as a strategic weapon in business, this notion of capturing the market through supply chain and delivery direct to the buyer is part of the culture. See Apple's Supply-Chain Secret? Hoard Lasers, for more background.

How to have a team of individuals with a shared outcome

I heard an interview on NPR with Steve Jobs. He stated...

We hired people to tell us what to do, not people who we needed to tell what to do.

 

What a concept. Whether it was true or not, the concept is powerful. Hire the best people, let them tell you how to make things faster, better, cheaper, or any measure of improvement.

Let these "brilliant" people invent the future, with Jobs guidance of course. Jobs told the story of the Mouse and the GUI. He visited Xerox Palo Alto Research Center (PARC) to see a demo of DynaBook.

What he saw was a mouse that cost a $1,000 and but needed to be $30. A GUI that would replace the screen and ASCII characters for all computers to date, including Apple II's.

But without the right people, none of that woudl have appeared in the Mac.

His last comment in the interview (1996) was that it is rare to have a company that actually does that - hire the people to tell the leadership what to do. Hire people to improve the products and processes. More common ego gets in the way, lack of listening to the market is the first step of lack of listening to your staff. Once you start down that path, only the followers will want to work there, the leaders will move on.

A Bit of Road Warrior Humor

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

Principles of Program Governance

When there is discussion around development, management of projects, agile, earned value and all the other "bottom up" processes that occupy the blog space, it's sometimes best to step back and consider what is really needed in the business and government world.

GOVERNANCE

Governance is about making the right decisions at the business level that impact the technical aspects of the work needed to deliver a capability. With the capability business "value" can be achieved.

All this agile talk about "value" rarely has any units of measure and turns into just a bunch of words, sometimes even nonsense words. The terms Mission and Vision are the starting point for the governance of projects and programs:

• Vision - Defines the way an organization or enterprise will look in the future. Vision is a long-term view, sometimes describing how the organization would like the world to be in which it operates. For example, "provide affordable manned space flight to low earth orbit using private funding."
• Mission - Defines the fundamental purpose of an organization or an enterprise, succinctly describing why it exists and what it does to achieve its Vision. For example - "build and operate a single stage to orbit vehicle with 4 Pacs that can operate for under $100,000 per flight."

Here's an approach to governance in the Enterprise IT world

Principles of program governance

View more presentations from Glen Alleman

If you print this briefing in the landscape format and bind it on the short side (left side) it will be a book that guides you through the Program Governance process.

The Myth of Standish Reports - Update

The Standish Report is raising its head again in the Agile presentations I've seen recently at conferences. Forgetting for the moment all the past "criticisms" of Standish...

• Standish Report
• Standish Report and Naive Statistics
• Finally a Challenge to the Standish Report

The numbers in the report are still being used by "agile thought leaders" to establish the basis for their proffered solutions. Forgetting even more that "agile" is a bottom up software development solution. And that most of the issues with large IT programs are leadership at the senior executive level, externalities from the market place at large, and general inability to connect the dots between business strategy and business execution.

Further is the complete lack of transparency in the statistical numbers. But here an alternative on how to report IT project success.

When you go here you'll see 61% are green, 33% "need attention," and 4.84% have "significant concerns."

The definitions of "needs attention" and "significant concerns" is provided in terms of mission suitability rather than simple - and simple minded cost and schedule.

So it's time once more to move beyond the worn out red herrings and start to address how to Increase the Probability of Project Success with processes and tools beyond just applying Scrum to the development team.

Willian poinnted out the bands for measuring success.  http://it.usaspending.gov/faq-agencies

Connecting Business "Value" with Project Performance Measures

Many in the agile community use the term "value" to mean business value, but in fact do not define the units of measure for this "business value." They leave that to the customer. The customer in many cases has no clue what it means to speak in "business value" outside their own business unit or possibly their own operational needs.

If we are to successfully connect the methods of Agile Software Development with business success, then there needs to be a conversation about what is meant by "Business Value."

Some in the agile community have confused the term "Earned Value" as it is defined in ANSI-748B with "business value." They do this through a simple mistake of not defining the domain, context, and units of measures.

Let's take a slight diversion and look at some classic comments from a vocal (but mis-informed) speaker about "value."

Earned value management is another lie – there is no value until the software is delivered. It is just not the right metric.

...this of course is the exact process of ANSI Earned value - measuring physical deliverables on planned boundaries - weekly or monthly for XP or Scrum - end of the Work Package for 748B programs (which BTW is usually has the Work Packages limited to one accounting period - a month)

Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.

... and of course this is simplly misinformation. Meetings are Level of Effort in EV and documents are discrete only if they are called out as a deliverable in the contract (CDRL) or needed for the proper operation of the software system - the pilots operating manual for the aircraft or the maintenance manual. Measures of progress are ALWAYS in tangible evidence - Technical Performance Measures (TPM).

True earned value, not documentation-based “earned value”

... nope wrong again, "documentation doesn't fly," is a common phrase in our manned spaceflight and aircraft business. Measures of performance for documentation are rarely used expect for LOE. "Flying software," is the best measure of performance for a flight avionics system.

Proponents of Earned Value Management (EVM)claim that it is an objective approach to communicating progress to stakeholders, enabling you to declare that you're X percent done at any given point in a project.

... ANSI-748B and the DoD Earned Value Management Intent Guide (EVMIG) call out the use of Technical Performance Measures (TPM) and Physical Percent Complete. It seems the author has been talking to folks who would not pass the Earned Value Professional (EVP) test or a DCMA Validation.

Measures of Effectiveness and Measures of Performance are Critical Success Factors for all projects

Independent of the actual experience or capabilities of the author in the Earned Value (ANSI-748B) domain, the "value" in Earned Value is not the same as the "value" in business value.

• Measures of Effectiveness - The operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.These are the "business value" measures seen by the customer.
• Measures of Performance - Measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.These are the software development performance measures seen by the development team.

Now that we've connected "business value" with "software development" value and addressed the unfounded conjecture that Earned Systems cannot be directly used with Agile's principle of measuring progress through working software it's time to see where this topic is being discussed with the proper background. The recent DoD Agile directive and the upcoming conference on Agile IT and the US DoD are places to seek information beyond conjecture.

In Earned Value practice, measures of physical percent complete are "taken" at the end of each iteration uses agile software development methods in EXACTLY the same way the measures of physical percent complete are "taken" weekly at the end of 0%/100% tasks or at the end of Work Packages on ANSI-748B DCMA Validated Earned Value Management Systems.

But that is for another time. Here's some more backgroud on using EV for "emergent" projects. Principles of Technical Management.

Connecting Business Value to the Measures of Performance for Software Projects

Here's an approach defining "business value" and developing measures of "business value" in the context of strategy - in this case IT strategy, and connects the dots between the value the business should be speaking about and the development of software intensive systems that implement that business value.  And how to start learning how EV is "actually" used.

Notes on balanced scorecard

View more presentations from Glen Alleman.

Proponents of Earned Value Management (EVM)claim that it is an objective
approach to communicating progress to stakeholders, enabling you to declare that
you're X percent done at any given point in a project.

Best Business Model Book Ever

Business Model Generation is the best book on this topic I have encountered. We're using it in place of several approaches to business modelling. By business modeling I mean the work processes for the business.

We're in our third year of developing a separate business practice focused on aerospace, defense, and federal government (FedCiv) services for Earned Value, Program Controls, Risk Management, some proposal elements, and other offerings around "programmatic activities." We're at the point now, with field sales, delivery directors, practice manager (me) and a full service team, that it's time to start asking "what are we going to do when we grow up?"

We can across this book in the airport, while waiting for the late plane. It's one of those books that you start to read while holding your Starbucks and then can't put down. It took a couple more trips through the airport before out team decided to actually buy the book. It doesn't fit nicely into the backpack, so I couldn't get anyone to carry it home.

The process defined in the book details the content and relationships between:

• Key activities - the most important things a company must do to make its business model work.
• Key partners - the network of suppliers and partners that make the business model work.
• Key resources - the most important assets required to male a business model work.
• Cost structure - describes all costs incurred to operate a business model.
• Customer relationships - describes the types of relationships a company establishes with specific Customer Segments.
• Customer segments - the different groups of people or organizations an enterprise aims to reach and serve.
• Value propositions - the bundle of products and service that create value for a specific Customer Segment.
• Channels - how a company communicates with and reaches its Customer Segments to deliver the Value Proposition.
• Revenue streams - represents the cash a company generates from each Customer Segments (minus the costs to create earnings).

There are several important things about this book. I'm reading and reviewing two "Agile Management" books. One is focused on "managing agile projects." The other is focused on building "agile management" processes. One is a personal view, the other is a reference based, academically sound treatise based on a broad spectrum of project and domains. The Business Model Generation book is the latter. I prefer the latter. The former is interesting, but too narrowly focused for general applicability.

Quote of the Day

Good writing is not written; it's rewritten!

Thanks to  John Goodpasture for providing this quote in his post about Red Teams. It triggered all the proposal development brain cells from past engagement. There are "color team" reviews during proposal development. The proposal development process is a Project itself. I've been on proposal teams that have a $20M budget, 100's of people, and multiple locations. Managing a proposal is not for the faint of heart. It's an all out, full contact engagement with a fixed deadline and usually a fixed budget and an emerging set of requirements.

Themes are the starting point all good writing. Why would the customer buy what we have? This is where clear, concise language is mandatory. I've been trained how to write proposals. It is a painful process, guided by feedback from the proposal manager - "you're section stinks, redo it by morning, and this time follow the theme outline!"

Here's some advice from 5 or so years doing proposals, technical memos, guidelines (Earned Value Management System Descriptions), and general business development writing in the DoD world.

Do not write so that you can be understood, write so that you cannot be misunderstood. - Epictetus

Most techies confuse features with benefits. People buy benefits, not features. Here's an example.

Many techies didn't get through that English class either:

• Emphasize present tense
  • Establishes credibility
  • Establishes that "some thing" real is being proposed
  • Poor - our project management office will publish monthy status reports to the contractor
  • Better - The project management office publishes monthly status reports to the contractor
  • The word "will" says to the reader there is an alternative - won't
• Use the first person plural- speaks to the reader directly.
  
  • Passive - the launch of our product will be in month 26
  • Active - we will launch our product 26 months from program start
  • Passive - Tom Thumb has been appointed our program manager
  • Active - Our program manger is Tom Thumb
• Use the active voice - passive voice is weak "we will" says strength. It is simpler, more direct and believable, forceful and confident, usually less wordy, and eaiser to understand.
• Be positive and confident- negative statement sound evasive
  • Positive - Mary often arrived late
  • Passive - Mary often did not arrive on time
  • Confient - Our cost accounting system ...
  • Conditional - Our proposed Cosrt Accoutning system ...   
• Nouns, commas, and the finer points of style- this and these are not nouns.
  
  • Poor - The new sales process has better quality. This is because ...
  • Better - The new sales process has better quality. This increase is due to ...
• Be specific
  • Poor - Our saling vacation was delayed because of inclimate weather
  • Better - Our sailing vacation was delayed because of high winds
  • Best - High winds in excess of 50 knots delayed the start of our sailing vacation

Write the thesis statement first, then tell the reader why this is a benefit

“Our affordable, supportable approach to Balanced Scorecard has line of sight visibility, providing actional information to the decision maker, built on the integration of all sales and warehouse performance data, for lower deployment and operational costs on a 12–week, low-risk delivery schedule”

– 30 words telling the reader why they should buy the benefit.

Addeum. Dominic pointed out the error in my use of feight versus faint. Common Errors in English Usage.

 

Foundation for Success

In the current issue of the Defense Acquisition Research Journal, there is an article titled, "Performance Based Life Cycle Product Support Strategies: Enablers for More Effective Government Participation."

It's one of those articles that we read every month in our domain about procurement, program management, Systems Engineering, and Test and Evaluation. Riveting stuff. All the topics we work with in our engagements with our clients, who themselves are engaged in government contracting.

What struck me in the article is the general applicability of the concepts. Concepts that can be applied across the board in almost every domain, where there is development using other peoples money. This notion of "other peoples money," is a good question to ask when someone suggests a method, a bold statement - like software development is not engineering, or the removal of some foundational principle - like planning what done looks like before you start. Would you do that with other peoples money?

Four Solid Foundational Elements of Performance-Based Programs

These four principles can be applied to projects where other peoples money is used to develop a product or a service. The notion of a "partnership," in which the funding element and the provider of the solution must work together for success.

1. Long Term Committed Relationships - executed with flexibility and integrated across organizational boundaries, with complementary skill sets and abilities.
2. Shared Partnership vision and objective - with the right metrics and incentives drive alignment and are especially effective when supported by clear delineation of complementary roles and responsibilities.
3. Full Coordination with all stakeholders - supported by transparency, open communication, and the flexibility to change partnerships scope.
4. Clearly Documented Objectives - support alignment and fuel the success of the partnership.

What Does This Mean - Really?

When we hear about some method, process, or principle, we can ask how that method, process, or principle supports these four elements of Performance-Based Program Management/

 

Strategy for Jobs

I rarely post about current events, not because I'm not interested, not because I don't have an opinion, but because this blog is about project management - the techncial side of project management. I got an email this week from a colleague that was distrubing enought to merit a post. Andy Grove has something to say we all need to pay attention to. Click is image to see the Bloomberg story, then if you work in the hightech or lowtech industry think again about our future.

What Does $35 Billion Look Like

Here's the binders for the EADS proposal for the KC-X tanker. The award is worth $35B over its period of performance. Photo source, The DEW Line

This is probably the largest award in recent years - no matter who wins (Boeing or EADS). Somewhere in those 17 volumes and 8,000 pages is the IMP/IMS and the Basis of Estimate content.

This concept is almost always missing in enterprise IT. Outside of the technical solution, the proposal needs to answer - How is the program going to be executed? What is the confidence that the plans, schedules, costs, and technical performance will turn out in the way the customer wants?

We're back to the core questions that must be answered for ANY project, no matter the method, the domain, context, or even the size:

• How much will this cost?
• When will we be done?
• How can we tell we're making the progress as we planned to make?
• What's going to be the impediments along the way and how are we going to handle them?

From experience on Crew Exploration Vehicle, the writing of the proposal was a $10M project in itself.

Can you say - Program Planning and Controls?