More Fuss about Earned Value and DoD

January 6th, 2011

Last month, Distributive presented a webinar discussing issues associated with earned value within the U.S. Department of Defense. (If you missed it, send an email to for the materials.) Since then, there continues to be activity in Congress to address the issue. The issue being that without technical measures, earned value is not an effective management practice for medium and large scale programs. Of course, the opinions about the scale of the problem differ. Let me paraphrase the various positions …

On one side is ANSI/EIA-748 and NDIA who hold that recommending the use of technical measures is adequate, as this provides the design agent/supplier with the latitude it needs to develop appropriate measures.

On the other is the GAO, DCMA, OMB and the not-so-shy Paul Solomon, who all claim that the practice of earned value must include technical measures. (Note: In the last webinar, I proposed a simple technique to address the fact that different programs have different technical measures.)

The issues resulting from not having technical measures are numerous: many common systems and software engineering practices simply fall through the cracks of earned value. For example, requirements creep, defect growth/quality (the “Quality Gap” is well recognized as an issue for EVMS) and churn/re-work are all examples of development activities that are not measured by earned value.

Anyway, in December of 2010, the annual authorization bill, National Defense Authorization Act (HR 6523) includes text to require that acquirers demand and suppliers put in place adequate technical measures.
See HR6523 here

The bill does not actually require changes to DoD policy and guidelines but at least there is recognition that something is wrong. Maybe by next year …

Putting MANAGEMENT into Your Requirements Management

October 8th, 2010

What’s all the fuss about managing requirements?

Flipping through, I came across an article, The Path To Successful New Products, from the McKinsey Quarterly which concludes that, “Businesses with the best product-development track records stand apart from their less-successful peers in three crucial ways.”  They studied the masters and found that, “The teams in our study that embraced these tactics were 17 times as likely as the laggards to have projects come in on time, five times as likely to be on budget and twice as likely to meet their company’s return-on-investment targets.”

When they took a closer look, one of the first things they report finding is that, “not thinking through a project’s scope early on–say an appliance maker asks developers to design a new cooking range in the four-burner category but then later expands the project to include ranges with six burners–can create delays.”  And that, “The teams with a clear understanding of project requirements appeared better able to make trade-offs between product performance and factors like cost, time to market and project risk.”

While requirements engineering and requirements tools have become widely adopted by software, systems and IT organizations, the number of project failures attributed to poor requirements management remains high.  And even though metrics that focus on requirements engineering are widely available, often only the most advanced and mature organizations actually use them.  Managers who do use requirements engineering measures are more in control and can spot trouble before the project becomes a death march.

For practical guidance on why and how to measure, and then manage, requirements, including recommended Requirements Management visuals, download our helpful white paper.

Check out our white paper on Putting MANAGEMENT into Your Requirements Management

Use Our Expert to Define the Best Information Needs for You

September 29th, 2010

Measure what you want to manage

The #1 New York Times bestseller book, The Happiness Project, maintains that, “You manage what you measure.”  It’s as true for happiness initiatives as business performance improvement initiatives.

The fact is that measuring a value (or not) changes the way we act on it.  In her blog, The Happiness Project author, Gretchen Rubin, says, “So figure out something you’d like to change in your life – more of something good or less of something bad.  Then figure out a very concrete way to measure it and to hold yourself accountable for living up to it.”

Precisely the same principles can be put to work for your organization or project.  Identify the key indicators of happiness according to your company’s goals and begin tracking them.  What gets measured gets done!

But where to begin, exactly?  What should you measure?  What to count and which graphs to use?  If only you had an expert to ask…

Visit our website to run the DataDrill EXPRESS Indicator Expert

P.S. Don’t forget to step back once and a while and check if the result you are getting is the one you want.  Prevent headachy mismatches between your goals and your metrics by measuring what you want to manage.

Focusing Measurement on the Information Needs of Managers

September 21st, 2010

Many companies struggle with providing solid, useful information to their decision-makers.  Even more so as the amount of available data swells and accumulates like snow drifts in a blizzard.  How does a company keep up?  How do you extract value from the data that helps managers do their jobs better?

In a recent conversation, Making Data Work For You, Forbes asked Marcus Schaper, principal at McKinsey & Co.’s Business Technology Office in Hamburg, Germany, just that:

Forbes: How do we keep up with an explosion of data and turn it into something truly valuable?

Schaper: This is a real challenge for many CIOs and many business units.  We are all swamped by data.  The availability of data is not the issue.  It’s how we can extract information from all of that data and make good business decisions from it.  That’s where many companies fail, despite the fact that many of them have very expensive and relatively good tools.

Forbes: How do they solve that?
Schaper: First of all, they have to ask the right questions.  Then they need to derive the right structure to bring the data into.  And finally they have to present it in a way that people can understand and trust.

So, let’s begin with asking the right questions. How do you know what information your organization should extract from its data to support good business decisions?  You identify your managers’ information needs and use them as the basis for developing a measurement process that is effective in helping you monitor and control your programs.  A bonus – managers spend less time gathering and analyzing the information they need to manage, so they can can spend more time on their real role: decision-making.

We’ve put together some simple techniques for extracting the real information needs within your organization, information needs that become the requirements of a successful measurement process.

Check out our white paper: Focusing Measurement on the Information Needs of Managers

Can Software Metrics and Agile Really Co-Exist?

August 26th, 2010

I came across an interesting article recently, from an analyst who claimed:

“Forward and sustainable progress can only be measured through a software system that works. There is no other way!”

What I found interesting is that while most engineers focus on the “software that works” part, most managers would focus on the “progress can only be measured” part of the phrase. In traditional “waterfall” style software development and in large-scale systems development, it is pretty much accepted fact that progress must be measured using those pesky things called metrics. People who use metrics are called “pencil pushers”, “bean counters” or other Dilbert-inspired names. It is interesting to note that metrics themselves pre-date the software development techniques we use today. Tom Gilb’s book on Software Metrics was published in 1976. Which means that somewhere along the line, after countless failures and disasters, the software development community started using metrics to control and manage software development.

Enter agile methods.

This gleaming development technique promises to speed software development, cut out useless documentation and rid the world of un-needed bean counters. I can’t help but be reminded of the article “No Silver Bullet: Essence and Accidents of Software Engineering” by Fred Brooks in the April 1987 edition of Computer magazine. For all you young, engineers thinking you’re part of some monumental shift, I can’t help but wonder if this is deja vous all over again. You see, what makes a software development technique actually successful (and I’m not talking about interest level and blog postings) is the extent to which organizations adopt and then keep the practice in its tool belt.

I see new software development techniques going through the same basic phases of adoption: incubation, viral adoption, wide-scale boasting and deployment, stabilization and then either implosion or integration into other business practices. Agile is currently leaving the wide-scale boasting phase and trying really hard to get integrated into “main stream”. I’ve seen a number of Fortune 1000 companies talk about their experience in happy co-existence of agile and traditional software teams. I am encouraged that quantitative management using software metrics are finding a way to co-exist with agile, which has a tightly focused set of measures.

Through the test of time, the jury has spoken on object-oriented design (it’s a HIT), spiral development (it’s a miss), and metrics (it’s a HIT). Let’s see if IT and development shops can incorporate the best of agile – and maybe we can make a dent in this whole chaos thing.


How to Manage Software Quality

August 11th, 2010

Before we can answer the question of how to manage software quality, we first must define what software quality is.  In assessing software quality, it is actually based on observations about the software in-use — how much or to what degree or how close to perfect does it provide the stated purpose of the software.

The Need to Manage Software Quality

So, why is there a need to manage software quality?  There are numerous answers to these questions such as avoiding a poor business fit, outages, security breaches, business dis-agility, data corruption and others.  All of these scenarios can be prevented if you know how to go about managing software quality, thereby saving your business from disabling losses.

Here is an example of a quality software problem.  To preserve the identity of the company, we will not divulge its name but designate it as company X, a healthcare provider.  Company X’s billing system is filled with quality problems up to the extent of collapsing completely, leaving the company with up to $400 million worth of patient’s unbilled invoices and $650 million of unpaid service invoices. This has resulted in the company’s stock market price dropping to a whopping 40% of its value and causing a cascade of negative effects.  This scenario typifies the importance of software quality management.

How to Manage Software Quality

The first and foremost goal of quality management of software is to discover any software defect during the first phase of the project in order to minimize the losses and disturbance it could cause.

There are four controllable features of quality and these are: (1) design and supervise the system and/or the user prerequisites of the project. (2) Trace the totality and intricateness of work products.  (3) Calculate the onset and advancement of defects.  (4) Lastly, begin calculating the point of origin of the defects.

So, here at Distributive Management we are making use of these four aspects to control the quality of software products.  Let’s take into consideration feature one, designing and supervising the system or user prerequisites.  Software quality monitoring is achieved by ensuring and knowing fully what the user needs through visibility via graphs and charts, thereby eliminating surprises.  Aside from this, the approval of the user requirement is done by several people to ensure that it’s correct.  Lastly, the team also keeps close surveys, again via graphs and charts, to check how close a match the actual usage of the project is to the planned or foreseen usage.

Peer Reviews, Now You Can Manage Them

July 26th, 2010

In every technology venture, it is important that your engineering or development team looks into the product being created to check whether the company is producing something that has value to potential customers. For this reason, peer reviews play a very big role in identifying potential product problems before they can impact customer satisfaction and lower market share.  When a peer review process is in place, appropriate action can be taken to remove potential problems before they affect end-users.

A peer review is basically the inspection of software along with a record of defects discovered by the engineers involved. Once a peer review is completed, the author of the software reviews the findings and takes appropriate action to correct them. In this technologically-advanced world, the author and reviewers don’t need to be physically present in the same location; the review can be done in a distributed fashion.

Peer reviews allow as many “IQ” points as practical to analyze, review and comment on a software product, without holding a lot of meetings. Contrast this to product development without a peer review process: a software product leaves the developers desktop and goes to testing without any method for checking for human errors, unintentional mistakes and misinterpretations.  On the other hand, with a peer review process, software defects are found efficiently and before it requires a lot time in testing and verification to find and report an error.

To ensure that it is effective, a peer review process should be planned and managed just like any other critical business process. Peer reviews can be very hard to manage but if you have the right tools to help you, then you can easily manage this particular task. One such tool is DataDrill by Distributive Management which can effectively help track peer reviews, defects found and code changed to make the entire business processes more effective. After all, an effective business also means more output and more profit.

With this particular tool (DataDrill), you will be able to monitor peer review productivity, then identify and spread best practices thereby distributing peer review techniques that work across the organization. This allows the development process to lower the number of software defects and effectively raising the software quality for users.

What this tool does is that it performs three vital functions: The owner of the enterprise set specific goals for which software is to be reviewed and how many defects are likely to be found. Peer review information is then sent to DataDrill which analyzes the data, calculates key performance indicators and reports this information to managers.  Finally, managers and stakeholders review the indicators and reports and take action when necessary to maintain acceptable product quality.

With the availability of an integrated and best practice solution such as the DataDrill solution, the entire management of the business can easily start managing the peer reviews instead of wasting a lot of time in defining the processes and deciding what to measure.

Benchmarking and Historic Data Capture

July 12th, 2010

In every business endeavor, it is really important to have benchmarking as one way that businesses compare their performance with competitors. Benchmarking is simply assessing the performance of your processes against the same processes within organizations in the same field or market.

Benchmarking is very useful in helping organizations avoid spending money without realizing any benefits. In many organizations, management decides to change engineering or development processes with the goal of improving their performance, or the quality of the product being produced. To determine whether the change actually helps the organization, the organization must have determined the capability before the change is made, and then compare the old capability with that of the new processes.   By comparing the two capacity numbers, or benchmarks, managers have the information they need to understand the value of the change.

In addition to using benchmarking to compare performance within the same company, it can also be used to compare the performance of one company with the performance of another. For example, how does the quality of the products from Company X compare to the products of Company Y? How about the productivity per employee … which one is more productive? These type of questions are exactly what benchmarking is intended to answer.

Organizations can use benchmark data to compare themselves on a periodic basis to their direct competitors as a method for determining whether they are becoming more competitive. Remember as your company is improving its business processes, so are your competitors! Staying up to date on benchmark performance is one way to ensure that your company remains competitive. Fall behind and there may be serious problems.

To perform either an internal or external benchmark, your organization must have historical data from your business processes which can be used for comparison. If you are using a tool like DataDrill from Distributive Management, then you have a central repository of all your critical data. To obtain data from competitors and other companies in your market, you can buy data from a number of benchmarking vendors, who specialize in maintaining private repositories of benchmark data.

Thus it is extremely important for companies to be able to have its own reliable system for capturing and using performance data. Developing such as system can be difficult thus this is where DataDrill comes in. DataDrill provides an efficient way of measuring the success of your company by using software that will be able to capture data and also provide good analysis which leads to better decision making by your companies management team.

Improving Process through Proper CMMI Implementation

June 19th, 2010

Once a business or organization grows beyond a certain size, it becomes more and more difficult to manage. In a small business, the boss can keep track of his employees, projects, and goals. He can personally check to make sure that everything is going smoothly. However, once he expands his business, he can no longer do this by himself.

There are a couple of models that can help businesses who have grown to a large size become more efficient in creating software, and CMMI is one example. CMMI stands for Capability Maturity Model Integrated, and it is a model for improving process. It works to measure, plan and monitor all processes. In this context, a process is all the steps and work it takes to develop and maintain software. This model looks at how to improve the processes and make them more efficient. This is helpful when you have a large number of people working together to develop software. Implementation generally goes in stages with improvements built on previous improvements to get to the maximum level of efficiency. It shows the company what it needs to do and in what order it should do these things so that it can improve.

If CMMI is properly implemented, usually by another organization or institution, then it can be very beneficial for a company. It is a very difficult model to implement so it is important to make sure that it is properly done so that it can have the best effect. This is why it is important to thoroughly research the institution that will be implementing the model.

This model can help a business or company become more efficient. When the company is more efficient in its software development then it can create new things more quickly. The business can also improve the quality of what it produces by using this model. Also this model can help a company make their processes less expensive, which helps the business save money. Increased efficiency and improved quality can help a company become more respected and, in the end, make more money, which is the goal of every business.

Measurement Requirements in Project Management: Process Metrics

June 15th, 2010

Customer relationships need a logical and efficient tool to go along with them to make sure they are as successful as possible; however, every business needs to define its plan before putting it into action so they have a clear image about what they want to accomplish.

The efficiency and productivity of a project can be measured by four types of metrics. These are the input, process, output and outcome metrics. Besides the input metrics which indicate the the quality, precision, accuracy and extent of a project, the process metrics shows the performance and efficacy that depends on deeds and actions. While output metrics indicate models, orders and proposals and the materials that will be customized and they become part of the deal, the outcome metrics show the financial part of the project.

Process metric is one important measure, targeting the customers, their loyalty and the overall business sales volume. Since it is connected to the customers, its main target is to measure customer satisfaction. The targeted persons are the recruit on sales. Every little aspect of a project can be measured; this is why using the right tools and metrics in the right place can improve the project and gives feedback abut what is going on for the moment and a solution for an existing problem.

The fourth metric, the outcome metric contains all the goods and activities which are hard to measure, such as long-standing relationships with a customer. However, a long term relationship with this satisfied customer cannot exist without the feedback of the other three metrics for the project owner.

A good project manager is aware that none of the four metrics is less important than the other, because the increased revenue (outcome) is the result of the performance and actions done in order to make the project roll. However, both process metrics and outcome metrics are data that reflect a business or project. Process metrics measure the energy invested and the outcome metric measure or try to measure the result, while they can measure the financial matters of the project.