PRICE Systems

Last week I was asked to participate in Career Day at my son’s elementary school.  I was both honored and humbled.  Honored because the school felt that my career was something the children would be interested in and humbled because I was forced to concoct a story that would make cost estimating and analysis both understandable and interesting to children from kindergarten through grade eight.  Fortunately the format was such that I presented to each grade individually so at least I did not have to come up with one story to address all ages.

The experience turned out to be a lot more fun than I imagined.  It’s amazing how many kindergarteners in my son’s school have parents that are scientists (although to be fair their teacher informed me that thirty minutes earlier, when a policeman visited the classroom, many of their dad’s were also on the police force).  Lots of forensic scientists I suppose! 

And it wasn’t really as hard as I expected, explaining what PRICE Systems does.  I used images of the kinds of hardware and systems that TruePlanning for Products can be used to estimate. While some of the younger ones thought that I actually had flown on the Space Shuttle, the upper grades got it.  The experience actually helped me learn several new things about my job.  First of all, I learned that what I do actually is interesting to kids who are starting to think about what they might want to do with their lives. The little kids were fun but the older kids were attentive and asked good questions.  The fact that my work contains elements of science and technology exploration, with math and a little bit of detective work thrown in was actually appealing to many of them.  I was also reminded of how much I like my job and why.  Not only does my job create lots of new and interesting challenges, it also gives me opportunities daily to help people who do software project estimating, hardware project estimating and system level estimating.  I get to help these people be more successful at their jobs by providing tools and methodologies that make their estimates credible and believable.

In a seminal RAND Corporation report, Bureaucracy Does Its Thing, author and former CIA agent K.W. Komer promotes the idea that the mindset of America’s institutions led to problems in Vietnam. His thesis is that the bureaucracies of the U.S. were fixated on fighting the Vietnam War according to how the bureaucracies had prepared and organized instead of in manner that the situation required.

As I read the stimulus package before Congress, I see a focus on the idea that new technology will create jobs. Yet I also have read that Governor Schwarzenegger is consolidating the technology departments in the California state government to reduce redundancy. This seems to make sense since technology tends to be scalable with a low marginal cost. Therefore, technology consolidation is strong budget-cutting tool but one that inevitably leads to workforce reduction.

Here is the question: should the government rely on technology investment as a way to bring jobs to the economy or has Governor Schwarzenegger discovered a blue print for reducing costs in cash-strapped states. My answer is: it depends on the situation.

This is where business case analysts and cost estimators become important. Indeed, technology creates jobs in terms of implementation but tends to reduce them in terms of operations. Business case analysts should take that into consideration as they consider cost-benefit trade-offs. Cost estimators also must take into account total cost of ownership of a project. Often times, there are implicit tasks that are "hidden" and thus, actual job creation may not be considered.

I choose not to hazard an opinion on the merits of the stimulus’s approach versus that of the California Governor. However, I will say that strong business case analysis and cost estimation will help eliminate pre-conceived notions in a given scenario. Therefore, these skills can keep us from falling into the trap that Komer described in his report.

                     
Like many others, I was astonished last Thursday by the images on my browser of those 155 extremely lucky people standing in the Hudson River.  And they certainly were very lucky last Thursday.  If you’re destined to fly on a flight bound for collision with birds, you want it to be piloted by a hero like Captain Sullenberger.  The incident made me think about what a hero is and how we all have the opportunities to be heroic in our chosen professions.

According to Wikipedia, a hero refers to a character that, in the face of danger and adversity or from a position of weakness, displays courage and the will for self sacrifice.  As a project manager you may not encounter danger daily, at least of a physical nature, but you certainly deal with adversity on many levels.  And courage is essential!

An heroic project manager is one who makes project decisions based on facts and who stands behind those decisions.  He or she defends the project team from those who wish to impose unrealistic deadlines and stands up to those who want to abuse or ignore the Project Management Triangle.  In order to be heroic, a project manager needs to have the tools necessary to plan a project right the first time as well as manage it with agility as situations change.  TruePlanning from PRICE Systems is just such a tool.  TruePlanning is the worlds leading solution for software cost estimation and IT Project Planning.  It gives project mangers the cost estimates they need to plan projects successfully and the courage necessary to defend those numbers to the naysayers.

Although the use of TruePlanning is unlikely to lead to instant fame or enable people to walk on water, a project manager who uses it regularly will be a hero to the team!
 

If you turn on the news or open the newspaper, you will definitely come across an item about the stimulus package. Obviously, there will be much debate to come over the price tag for the initiative. But I wanted to take a moment to discuss where resources will be directed and how they will be dispersed. I also would like to talk about how this bill might affect us in the "Land of Estimation."

High-tech is the theme for this stimulus. Most projects will involve technology upgrades of one sort or the other. Even shovel type projects will have a futuristic spin to them. For example, school repairs are geared toward energy efficiency. Health IT, alternative energy and high-tech manufacturing are at the top of this agenda.

An even more important point is that not a lot of new bureaucracy will be created. Instead, existing federal bureaucracy will be expanded. For example, the Manufacturing Extension Program, a Clinton-era initiative, will receive more funds. The Office of the National Coordinator, a Bush-era Health IT office, also will receive more funds.

So what does this mean for business, in general, and estimators, specifically?First, partnerships will be essential. Estimators should partner with federal agencies and programs on the dispersal side. These groups will be focused on accountability and affordability. Their goal is that no dollar is wasted. On the reception side, partnerships should be formed with states and industry-leaders. These groups will be interested in developing accurate business-cases. Their goal is to demonstrate that their projects create value.

So, the stimulus will indeed be controversial. But it also may create a golden opportunity for the estimation world.

Today, change is in the air.  As I write this, Barack Obama is about to be sworn in as our new U.S. President and the space community, among others, should be braced for change.  A recent LA times article reported that of the 74 questions asked of NASA by the Obama transition team, over half were on basic spending issues, including cost overruns.

The Obama team and the NASA Administrator Michael Griffin clearly do not see eye-to-eye.  Monday, it was announced that Mr. Griffin will step down from the post.  Griffin characterizes himself as an engineer and states that NASA shouldn't be evaluated by how well it estimated the cost of projects.

"We start these things out, and we admit up front we don't completely know how to do them. That is what makes them interesting," Griffin said recently.

"If we are to judge the worth of our work by our ability to estimate, then that is a standard I am not ready to apply or to accept," Griffin said.

Others are more realistic about NASA's obligation to create credible expectations for spending taxpayer money.

"Our space program is running inefficiently, and without sufficient regard to cost performance," wrote Alan Stern, a former NASA associate administrator who has been mentioned as a possible replacement for Michael Griffin, the current NASA administrator.

In a recent op-ed piece in the New York Times, Stern called the cost overruns a "cancer" that has cost the agency's science program about $5 billion over five years.

Agency officials said they had improved financial controls -- including forcing managers to better estimate costs.

Considering NASA's great technical achievements, one must wonder, "Is accurate estimating harder than rocket science?" 

I don't think so.  I believe the clue to accurately estimating the cost, uncertainty and risk associated with large, complex space projects can be found in a recent Defense AT&L article by Col. Brian Shimel, USAF.  Col. Shimel states,

"We cannot relieve ourselves of the need to plan for the future just because the future is uncertain. For our plans to be reasonably accurate and reliable, it is prudent we base them on rational analysis and not on wishful thinking.", and...

"We must think clearly about uncertainty and risk, and we must fight the temptation to discount those factors when communicating the real conditions of our management situation. We don't get in trouble because of risk and uncertainty. We get in trouble for not admitting to ourselves - and those who rely on us - all of the risk and uncertainty that inherently exist in everything we plan to do."

Our TruePlanning estimating and cost management software gives managers metrics and benchmarks of previous projects, and methods to realistically quantify uncertainty and risks.  TruePlanning's reports and charts expose over-optimism and show managers the real conditions of the situation.  I routinely recommend that government agencies quantify all the risks and uncertainties of each project in their portfolio and budget to the sum of the 70% confidence levels of each project, yielding 80% confidence that the projects can meet taxpayer expectations for the budget.

President Barack Obama just finished his acceptance speech.  He called upon us all to increase our service to the country.  Government managers can help by stepping up to the estimating challenge.

Accurate estimating is not rocket science.  There are sophisticated cost estimating models to accurate estimate software development costs, hardware development costs, IT project costs, and operation and support costs - we just need to be realistic, responsible and courageous about presenting the results for our analysis. Contact us and we'll help you get started today.

It seems that, even in the midst of billions of dollars of bailout funds, the federal government is taking accountability a little more seriously.  Politics aside, the government is making the effort to ensure that every dollar spent is an investment rather than waste.  As we all know, industry follows the lead of government. 

We see this effort for accountability in a recently introduced Senate resolution (that will be re-introduced in the next Senate), S. 3384. The Information Technology Investment Oversight Enhancement and Waste Prevention Act of 2008 was sponsored by Sen. Tom Carper of Delaware.  The act was a result of IT cost-overuns in the Federal government.

The Act requires that Federal CIOs provide Congress a business case/baseline estimates for IT Investment Projects as well as performance reports.  Gross deviations must be reported to Congress along with a remediation plan.  All estimates must be independent.

So the implied task for Federal CIOs is to develop a framework for creating independent cost-estimates and conducting gap analysis between baseline estimates and actual cost.  Knowledge of the framework will be a pre-requisite for project managers and planners.  Eventually, these practices will trickle down to the private sector.  Parametric cost estimating based on industry data may provide a foundation for such a framework.  Ultimately, parametric cost-estimating can be the key to IT accountability!

This was a fun and gratifying week at PRICE Systems. In our Mt. Laurel, NJ headquarters we had our annual holiday gift wrapping of presents we donated for needy children and families in the area.  The PRICE team gathered in our classroom and the wrapping began with no pre-instruction or guidance - but much merriment.  What a study in production process and learning!  Wrapping that first present was awkward.  It had been a while since I wrapped last.  How to measure the paper?  Where to cut?  How to keep the cut straight?  Which way do I fold first? How to fold?  What to do if I have too much paper on the ends?  Where do I put the tape?  ...and so on.  Needless to say that first present took some time, I wasted a lot of paper and tape, and the final product had some wrapping defects.  After reflecting on the results, I looked around at others to see what they were doing, asked some questions, processed that information along with my own experiences, and set out on the second package.  I did much better.  I wrapped faster, I wasted less, and the final product was an improvement over the first.  With each new gift I got better and better.  I "learned" how to be more productive, reducing the effort and materials with each present.  By the eight present, I started to focus on how I could reduce materials.  How can I use less paper?  How can I use the least amount of tape and still keep the paper form coming off?  I was improving the overall process.

Productivity increases like mine occur with each and every production process and it is an essential part of cost and schedule estimating.  The method most commonly used to model this effect is called "learning curve", and we use it in all of our models. You can find hundreds of references and equations on the web, but generally the model uses a "learning curve parameter" (LC) to estimate the cost for a certain production quantity.  The LC is expressed as a percentage, and (1-LC) represents the amount the production cost is reduced every time the quantity doubles.  For instance, if I say an 80% learning curve applies to the process, then every time the quantity doubles the cost to produce is reduced by 20%.  So if the first unit cost $100, then the second would be $80, and the fourth would be $64, and the eighth would be $51.20.  For the same starting point, a 90% learning curve represents less learning and higher costs, while a 70% learning curve steeper learning and lower costs. 





If I had timed my wrapping and measured the materials used, I could have used simple math to determine the learning curve that applied. I suspect it was close to 70%.  Determining the learning curve for everything from paper clips to space ships is more complicated, but that is one of the things we do at PRICE.  We perform operations research and analyze data to keep our models as accurate as possible, and embed that research in our cost management software.  Accurate learning curve estimates help our clients optimize their investments, prepare better budgets, plan more effectively.  And as part of this most recent study, we made  a lot of kids happier for the holidays.  Happy Holidays to you. 

A recent Gartner report indicates that industry enthusiasm for SOA is waning.  The reasons cited are the lack of enough people with the proper skill sets to perform SOA deployments and the lack of a good business case for SOA.  It’s an interesting but not really unexpected direction.  SOA has been surrounded by significant hype, ensuring that organizations surveyed would be anxious to profess their desire to start a SOA project.  But as the rubber hits the road, these organizations are realizing that SOA may not be the answer to all of their organizational woes.

Many will argue that SOA is nothing new – but rather a repackaging of an object oriented approach to software reuse.  They insist that the reason for this repackaging is motivated by a strong marketing push to sell a new generation of tools to folks that were not successful achieving reuse with earlier versions of tools.  Although I agree that the notion of SOA is not new, I do believe that technology has been advanced to a level where enough abstraction can be applied to the process to make reuse a possibility.  I do agree with the cynics that the heavy marketing push for SOA has not helped businesses make thoughtful decisions about whether it is right for them.

Now that enthusiasm has been tempered, organizations are starting to look at the costs, benefits and ROI of SOA.  This is a good thing.  A more thoughtful approach across the industry will balance the effects of aggressive marketing and ensure that the right SOA projects are attempted.  Of course, the challenge of determining ROI is daunting, particularly without a lot of data. Determining the benefits of a relatively untested paradigm is problematic.  If the SOA vendors are to be believed the benefits are tremendous.  Experience of course tells us that this is optimistic.  But common sense indicates that there is a great deal of potential for benefit for businesses that meet one or more of the criteria listed in the article “Your SOA needs a business case” – in other words if your business must respond to frequent changes in the marketplace or with business rules and relationships.

Understanding, or predicting, the benefits SOA will bring to the organization is only half the challenge.  The costs associated with a deployment of capabilities in a service based framework are also an important consideration.  The TruePlanning Suite, available from PRICE Systems, can help in this area.  TruePlanning allows for IT Project cost estimation that will help address costs associated with deploying the right infrastructure for SOA, the costs associated with development of services, and the costs associated with the composition of applications using services.

Technology readiness is a critical cost driver of development programs.  Many high technology programs fail because initial cost and schedule expectations were based on the assumption that the technologies employed were proven,  when actually they were not. Space programs have the most dubious history in this regard.  I once listened to a Lockheed Martin executive explain how the X33 space shuttle was a great vehicle, but was canceled because it was, "two inventions short of meeting the requirements". Canceled after over one billion dollars were spent.




Starting development projects that have constrained budgets and schedule with unproven technology is a bad idea, one that has not gone unnoticed.  The Defense Acquisition Performance Assessment 2006 (DAPA) report states,

"Technology maturity or “knowledge-based” development has been a subject of considerable discussion between the Department and the Congress. However, although there is agreement concerning the advantages of ensuring that technology is mature prior to proceeding to development and production, there are no clearly definable measures of technology readiness.", and,

"Incorporating high-risk technology in systems generally leads to significant cost and schedule impacts."

So, have decision-makers learned their lesson by now. Recent news suggests not.  It was just published that NASA's Mars Rover mission was delayed two years and is over budget because,

"problems developed in the design and operation of the 31 actuators that control the mechanics of the craft, including the steering mechanism and its robotic arm"

Probably a few inventions short.

Technology should be matured in a lab environment with a sustained level of effort before it is employed in a development project with cost and schedule constraints.  Anything else is extremely risky and will most likely fail.

The PRICE TruePlanning models each have a method evaluating the cost and risks associated with technology maturity.  Our cost management software helps our clients decide among  alternatives with varying technology maturity and let them know the risk of overrunning cost and schedule.  Most of the time our analysis can dissuade executives from starting a project "two inventions short".

Software cost estimation is hard.  I have learned this the hard way – as a software developer and later as the manager of software development projects. Today, as a builder of cost estimating software, I learn something everyday about software development that reinforces the fact that software cost estimation is hard.

I attend a lot of trade shows and I talk to a lot of software people about how they estimate software costs.  Many of them have no formal process, many don’t collect data as projects progress, many of them perform estimates off the cuff, and many of them, not surprisingly, are unhappy about the outcome of their software development projects.

Many of these same people are quick to point out, when presented with possible help in the form of TruePlanning for Software, why it will never work for them.  Nine times out of ten, the reason they give me has to do with the uniqueness of their product, their customer base, their market or their software development process.  They question the data behind the model and suggest that this data can not be successfully translated to properly model their specific situation.

And I can’t fight the uniqueness argument – it’s most likely true.  Every software project has factors that make it different from all the other software projects that have occurred in the past.  No two software projects are the same.  I can however argue about the suitability of the data behind my model. The majority of software projects are not defined by their uniqueness.  There is much more about most projects that is similar to other projects than is different.  A good software estimation tool like TruePlanning for Software capitalizes on this fact by allowing the user to take advantage of industry or organizational data for those many places where a project is not unique.  Further, it offers expert systems like guidance to transcend those areas where a software project veers from commonplace to extraordinary.

In software, as in life, we tend to put the most focus on the parts of a project that are challenging and interesting with much less focus on the parts that are ordinary.  If, in doing this, we are discounting the lessons we can learn from history, we are doing ourselves and our software projects a disservice.

Jacob has a great comment to my recent post on getting it "right the first time".  He notes that requirements are often fuzzy and that estimates rely on peoples' opinion of cost and duration - and that the are often wrong.  He asked what silver bullet we have. Our silver bullet is a proven discipline that makes people better estimators and sheds light on fuzzy requirements.

It starts with the people. Becoming an accurate estimator requires the same step-by-step approach as any learned skill such as golf or tennis or swimming (things I am currently struggling to do well). First you need the right tools, then you need to learn the right way, then you need to be mentored by experts as you practice what you learned until it becomes second nature. Recently, I was struggling with my breathing while attempting to swim. Lap-after-lap I was breathing hard, swallowing water - it was a miserable sight.  Then I consulted an expert that got my head turning the right way and got me into an rhythm of breathing every third stroke.  My swimming quickly improved by 40% - more laps in less time.

We do the same for our clients.  First we arm them with the right tools.  Our TruePlanning software provides a proven step-by-step discipline to do an estimate the right way,  TruePlanning asks the right questions and covers all the bases, including risks.  Then we train people not just how to use our software but how to be great estimators.  Sizing methods, interview techniques, and requirements elicitation are part of our training.  Then our experts are by their side as they hone their skills through email, live-meetings, a 24/7 hot-line, and on-site visits.  Throughout we provide people with benchmark measurements of other similar efforts and tips to guide them. Suddenly fuzzy requirements become clearer. People are doing more accurate estimates in less time. Typically our clients improve their estimating accuracy by 50% within three months and several of our clients now produce estimates that average within 5% of actual scope, cost, and schedule.  Our clients leverage our cost estimating software and cost management software to estimate software costs and schedules, IT infrastructure costs, and custom hardware to improve their overall project and portfolio management.  By the way, I just finished a mile in the pool and improved by another 10% - practice makes perfect.

According to Gartner, Service Oriented Architectures (SOAs) will be used in more than eighty percent of mission critical operational applications and business processes by the year 2010.  Perusal of the literature on SOAs leads to visions of ease of implementation and cost savings of epic proportions.  And it is likely that not only will service oriented implementations results in cost savings, but that without them many currently envisioned capabilities in the corporate world and the Department of Defense (DoD) will be impossible to deploy, maintain, and evolve as technology explodes and requirements and priorities shift.

As with all technology shifts, the cost savings are neither automatic nor are they immediate.  Up front investment is necessary before the cost savings start to roll in.  Businesses are anxious to begin deploying SOA capabilities but are wary as to what the transition may cost them. 

This is an area that we at PRICE are very interested in, not only because we want to help our clients overcome this software cost estimation challenge, but also because we are investigating ways that SOA concepts will help us better serve clients of the TruePlanning Software Cost Estimation capabilities. 

For purposes of understanding cost implications, a SOA deployment can be segmented into three general areas.  The implementation of the infrastructure necessary to host service based capabilities is a significant investment for a company.  This generally requires a search for the right set of commercial off the shelf middleware components to meet the business’s requirements for security, performance, etc.  The deployment of the infrastructure is a one-time investment with costs being driven by the specific requirements of the organization and the level of technical maturity with respect to SOA.

Once an infrastructure is in place, services need to be developed and existing capabilities need to be migrated from traditional applications to services.  As services are really just software implementations,  drivers in this category are similar to typical drivers for software development costs.

Finally there is an integration and test effort associated with getting services working within the context of the infrastructure to deliver value to end users.  In many ways this effort will be similar to other software integration and test efforts but additional factors will come into play. It's important to understand how the rigor put into developing the infrastructure will impact the cost and effort of actually using that infrastructure to deliver capability. Read more about on-going research into the costs and benefits of Service Oriented Architecture.

As I prepare my remarks for the first PRICE Systems International Symposium and User Group Meeting in Asia hosted by the PRIGENT corporation, I am astounded by the recent globalization of the Defense Industry.  Worldwide weapon systems acquisition has been permanently changed by: 

Today, BAE Systems is the sixth largest U.S. defense contractor, U.S. defense contractors dominate European Defense top-ten lists and S. Korea is building its global customer portfolio, including Turkey. Among of the greatest challenges to this newly globalized industry are communication and understanding between customers and contractors, and among the internal organizations within a multi-national corporation. Defense procurement agencies and contractors wishing to succeed in this new world must adopt new communication strategies. 
One of those strategies will be evident at our event.  Negotiations to set the right price and to determine the ensuing operation and support costs are difficult in this environment.  Cost models, which work in the precise global language of mathematics, are the Rosetta Stone in the procurement Tower of Babel.  At our Symposium TruePlanning and the PRICE models will be the common language among Defense procurement professionals from around the world. And they will have little trouble communicating and understanding because the models distill their differences down to a universal set of cost drivers, activities, and resources common to all projects. We will discuss estimating software costs, IT project cost estimating, the effect of software development tools, the challenges of project planning and budgeting - and there will be understanding. When we used acronyms to name our model parameters, an arcane term like ECMPLX (engineering complexity) became the global term for describing the technology maturity and engineering experience of a development task.  Today, our clients from around the world have a universal understanding of our model parameters and can communicate and negotiate effectively using our cost estimating software.  Everyday, I see evidence of vast productivity improvements when multi-national companies and international procurements standardize on our models and cost management software, establishing a common language in the midst of diversity. 

Is it like a Tower of Babel where you work? Consolidation is occurring in nearly every industry today, so think about the efficiencies that can be gained through standardization?  ...communication?  ...immediate understanding?  As you improve communication and understanding, you will become more productive and estimate more accurately.  

A good point is made in a comment to my last post, Chris Carter says, "As estimators I think it is our duty to tell our customer (management) what we assess the possible range of outcomes to be so that they can make use of this information ".  I agree that we should always deliver an indication of accuracy every estimate.  Uncertainty and risk analysis is an integral feature of TruePlanning and we educate our clients on the value of estimate ranges to optimizing project and portfolio performance. The uncertainty-based probablistic confidence-level of an estimate that our products produce is an effective means of addressing the issue. Your cost estimating tools and cost estimating software should address uncertainty and confidence so that weapon system project planning and IT budget planning can be optimized.

Many times estimating software cost is the major challenge. I recently came across a strong case for estimating accuracy and the value of risk ranges in a recent Forrester Research report titled,  “Debunking IT Project Failure Myths,” by Lewis Cardin, a former CIO and currently senior analyst. The twelve-minute Podcast is worth a listen. Mr. Cardin found that among the top reasons projects failed were:

[Begin quote]
1. An unrealistic project plan, which dooms the best project.
All too often, when these projects go on the rails of the original project plan, PMs must spend more time on damage control with steering committees and project resources rather than on execution — doubling their work when it is least desirable to do so.

2. First-number syndrome, which makes business execs forget it’s an estimate.
When projects are first sized, which is likely to occur before they are approved, estimates of cost, time, and resources are preliminary with a wide confidence interval…. But business execs remember the number and forget how uncertain it is…[and] may see this simply as increasing costs, not as the inevitable result of greater knowledge.
[End quote]

I have seen these two factors kill many good projects and ruin the careers of many good people.  I served on the "Intenational Space Station Management and Cost Evaluation Task Force" (IMCE) for NASA and this was exactly the situation with that program.  My experience there prompted me to compile "Six Steps to Program Success" where, "Getting the estimate right the first time" is the most important step. It is so important that you create the right expectations at the beginning of project by presenting the possible outcomes, good, bad, and ugly.

Estimating accuracy is not just about one number. It applies to risk ranges and confidence-levels so that management can determine the right number that goes into the bid or budget.

Martin Woodward ‘s comparison of software development to Sudoku does an excellent job of explaining why software cost estimation is hard.  We constantly hear about software development projects that are unsuccessful because they have violated one or more aspects of the Project Management Triangle  - they are either delivered late, delivered over budget or fail to deliver the capability that users require. And while I firmly believe that software development is an engineering discipline, software project estimation is often more complicated than estimation for other engineering disciplines because software project output is not nearly as easy to quantify and because there are other intangible factors that impact the software development process - the same kind of intangibles that Woodward mentions in relation to a Sudoku puzzle.

Woodward also does a great job in describing how agile software development practices help with software project estimation.  When employing agile development practices, an organization effectively embarks on a new software development project with every iteration (an iteration is a small chunk of time -  usually one or two weeks long - during which the next 'release' of software is completed). The tenets of agile require frequent releases and frequent customer reviews.  These reviews often trigger reprioritization and re-estimation. The agile team develops its own system of software measurement and quickly becomes good at estimating the work required for any given iteration. Agile also promotes good development practices to ease recovery when intangibles threaten to unhinge the Project Management Triangle.  

If every software development project is a two week venture and the development team is very good at estimating the next iteration, why would an organization require a software estimation tool like TruePlanning by PRICE Systems?  This, of course, is an excellent question.  It is true that the software development team doesn’t need a software estimation tool but the organization still does.  The organization needs to be able to put together credible a credible product roadmap.  Customers and sales people still want to know what’s up next and when it’s going to be available.  And although the nature of agile development indicates that content might change, the knowledge of the agile development team will actually help the organization use a software estimation tool successfully. 

Agile is all about measurement.  Successful software cost estimation, even with a great tool, requires good measurement practices.  The tool is the framework for success, but good metrics customize the framework for a specific organization.  Agile organizations that can combine their data with a framework like TruePlanning  can optimize their ability for successful long term planning.

While working with clients who operate under fixed budgets I often hear, "Cost is not an issue when we plan and budget, so why is estimating important?".  I quickly stress that estimating is not just about cost.  It about balancing project scope, cost, time, benefits and risks. If your estimates are not accurate, your projects and portfolios are not optimized – and you are wasting money.

Projects are planned and managed within scope, time, and cost constraints. These constraints are referred to as the Project Management Triangle.  Each side represents a constraint.  One side of the triangle cannot be changed without impacting the others. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

The discipline of project management is about providing the tools and techniques that enable the project team to forecast, anticipate and organize their work to meet these constraints.  The discipline of portfolio management is about using tools and techniques to provide management with accurate estimates of cost, scope and time for each ongoing and proposed project so that they can make the right decisions to optimize their objectives within overall constraints. Every day, project managers and business leaders make decisions based on estimates of the dynamics of the project management triangle.  Since each decision can determine whether a project succeeds or fails, accurate estimates are critical.  Projects launched without a rigorous initial estimate are five times more probable of experiencing delays and cancellations.   Even projects with sound initial estimates are doomed if they are not guided by informed decisions within the constraints of the triangle.  If you are working under a fixed budget (cost constraint), then an inaccurate estimate of the number of product features you can produce (scope) within a fixed period of time (schedule) will doom your project.  Inaccurate estimates across your projects de-optimize your portfolio. 

Unfortunately, most project management tools only balance cost and schedule. Tools like Microsoft Project, CA Clarity, Primavera, and others do not link cost and schedule with scope.



Project modeling and estimating tools, like TruePlanning by PRICE systems, maintain a persistent link among project scope, cost, schedule and risks.  With project models, project managers can instantly see the impact that changes in scope have to costs and schedules.  Any side of the Project Management Triangle can be constrained while "what if?" analyses are performed.  Accurate estimates optimize the balancing act.

Successful organizations recognize that estimating is not just about cost, but about balancing within constraints and optimizing results.  They respect the triangle.

Software size measurement continues to be a contentious issue within the software industry.  While the software engineering community has made significant progress in it’s quest for the right way to assign value, the journey has not been without missteps and detours.  And there is still more work to be done.

When I first started programming it never occurred to me to think about the size of the software I was developing.  This was true for several reasons.  First of all, back in the day, software had a tactile quality through the deck of punched cards required to run a program.  If I wanted to size the software I could touch, feel or eyeball the deck to get a sense of how much there was.  Secondly, I had no real reason to care how much code I was writing; I just kept writing until I got the desired results and then I moved on to the next challenge.  Finally, as an engineering student I was expected to learn how to program but I was never taught to appreciate the fact that developing software was an engineering discipline.  The idea of size being a characteristic of software was foreign to me – what did it really mean and what was the context?  And why would anyone care?

Twenty five years later, if you Google the phrase “software size” you will get more than one hundred thousand hits.  Clearly there is a reason to care about software size and there are lots of people out there worrying about it.  And still I am left to wonder – what does it really mean and what is the context?  And why would anyone care?

It turns out there are several very good reasons for wanting to measure software size.  Software size is an important component of productivity and quality metrics.  The ability to measure productivity and quality are an important part of any process improvement initiative.  The ability to measure size is essential to successful software project estimation.  Additionally, a good software size measure could conceivably lead to a better understanding of the value being delivered by a software application.  The problem is that there is no agreement among professionals as to the right units for measuring software or the right way to measure within the units we use today.  Read more about Software Measurement.