Tag Archives: estimation

QSM (Quantitative Software Management) 2014 Research Almanac Published this week!


Over the years I’ve been privileged to have articles included in compendiums with industry thought leaders whose work I’ve admired.  This week, I had another proud moment as my article was featured in the QSM Software Almanac: 2014 Research Edition along with a veritable who’s who of QSM.

This is the first almanac produced by QSM, Inc. since 2006, and it features 200+ pages of relevant research-based articles garnered from the SLIM(R) database of over 10,000 completed and validated software projects.

Download your FREE copy of the 2014 Almanac by clicking this link or the image below.

almanac

(Mis)Perceptions about Software Estimation – Opportunities or Crisis?


Dr Dobb’s online published my article on this topic this week… and quickly comments started pouring in.  Some asked why I would publish an article with observations without solutions while others implied that this is really a customer problem or a human communications problem (I agree with the latter) –  What do YOU think?

Read it, and PLEASE give me your feedback.  Do you agree, disagree, don’t care?  Inquiring minds want to know!

Dr Dobbs

 

 

Dear Carol: Collecting Metrics Willy Nilly doesn’t make Sense


Collecting software development measures sometimes appears futile… here’s some sage advice from my QSM Inc advice column. Enjoy!

Collecting metrics willy nillyClick here to read the full article.

p.s., I love getting comments or hearing if what I write makes sense to you! Carol

 

What’s the Point of Estimating?


Here’s the latest installment of my QSM Ask Carol blog:

Point of estimating

“What’s the Point of (Early) Estimating?”  … click on the image or the title here to read the full blog post.

-Carol

Latest installment of Ask Carol: No matter What… in Project Management, Size Matters


Just wanted to share with you my latest installment on the QSM website blog – My Dear Carol advice column.  Enjoy!

Ask Carol - size matters

Here is the link to the rest of the article:  http://www.qsm.com/blog/2013/ask-carol-no-matter-what-project-management-size-matters

Fundamentals of Software Metrics in Two Minutes or Less


 

Fundamentals of SW Metrics in two minutes or lessTo read more click on the link:
http://www.qsm.com/blog/2013/fundamentals-software-metrics-two-minutes-or-less

What Can Goldilocks Teach about Software Estimating?


goldilocks

http://www.qsm.com/blog/2013/what-can-goldilocks-teach-about-software-estimating

Comments?

Fundamentals of Software Estimating: First see the Elephant in the Room Part 4


This is the last in a series of four posts (and more to come) on BASIC software estimating concepts that address the “WHAT IS IT?” we plan to estimate.

Upcoming posts will address:

  • Fundamental principles of estimating (micro estimation versus macro estimation; probabilistic estimation, degrees of uncertainty);
  • What can and should an estimate be used for?
  • Pitfalls and missteps in software estimation
  • Do you need a tool for estimation – including a survey of the most popular software estimating tools
  • Does size matter?  Shortcut approaches to software sizing
  • Succeeding with estimation – creating a Software Estimating Center (with or without a Project Management Office PMO)

Introduction

Whenever I teach project estimating or Project Management 101 (basics) to software developers, we address the fundamental questions about what we plan to do (once called “The Triple Constraint” in project management circles):

What amazes me, is that while these are great questions that need to be answered when we do an estimate, we start out by ignoring the “Elephant in the Room” – that is, what do we mean by the “it” in the questions above.  Sure, for some people “it” may be obvious that “it” is a project, but bear with me for a minute… misunderstandings about terminology and definitions are often the source of major rework when software construction is involved.

What is “it”?

  1. “It” could be the project (and all that the term entails);
  2. “It” could be the resultant product (software and/or hardware);
  3. “It” could be a phase or exploratory R&D effort; or
  4. “It” might be something altogether different...

The question of “what is it?” we are estimating is fundamental to why IMHO (In My Humble Opinion) software projects end up being over budget, late, and out of scope.  If you don’t know definitively WHAT you are estimating, how can any possible estimate be realistic?

This post is Part 4:  “It” is something completely different (i.e., not a project, a product, or an R&D effort)

When the “It” is production systems support (i.e., keep the systems up and running) or help desk (answering calls and troubleshooting) or product installations, the first question remains – how big or how large is the scope?

The following types of questions need to be answered to help size the scope to be estimated:

  • What length of time will the estimate be intended to cover (i.e., a year is typical)
  • What applications are to be supported/included?
  • What level of support is needed (24 x 7 or five days per week or some variation?)
  • What is included in the work (analysis, troubleshooting, training, rework, enhancements, etc.)?
  • How many users use the system(s), how often (daily, weekly, all the time), how many locations are being supported (geographically dispersed?), are there multiple languages that need to be supported?
  • Does support include time for vendor liaison for supported/installed packaged software?
  • Is support variable throughout the period to be estimated or consistent? (i.e., are there critical performance periods (such as yearend) during which the support needs to be increased?)
  • Are there service level agreements that govern the quality and responsiveness of support?

This list is not exhaustive, however, it does outline the major considerations for scoping out support or help desk activities or installations.  Knowing the goal and the scope of such efforts is the first step in being able to realistically estimate support.

The next post…

Takes a basic look at the components beyond figuring out what is to be estimated (the critical first step).  I hope you’ll join me then.

–Carol

Fundamentals of Software Estimating: First see the Elephant in the Room Part 3


This is the third post in a series of four posts (and more to come) on BASIC software estimating concepts that address the “WHAT IS IT?” we plan to estimate.

Introduction

Whenever I teach project estimating or Project Management 101 (basics) to software developers, we address the fundamental questions about what we plan to do (once called “The Triple Constraint” in project management circles):

What amazes me, is that while these are great questions that need to be answered when we do an estimate, we start out by ignoring the “Elephant in the Room” – that is, what do we mean by the “it” in the questions above.  Sure, for some people “it” may be obvious that “it” is a project, but bear with me for a minute… misunderstandings about terminology and definitions are often the source of major rework when software construction is involved.

What is “it”?

  1. “It” could be the project (and all that the term entails);
  2. “It” could be the resultant product (software and/or hardware);
  3. “It” could be a phase or exploratory R&D effort; or
  4. “It” might be something altogether different...

The question of “what is it?” we are estimating is fundamental to why IMHO (In My Humble Opinion) software projects end up being over budget, late, and out of scope.  If you don’t know definitively WHAT you are estimating, how can any possible estimate be realistic?

This post is Part 3:  “It” is a phase or exploratory R&D effort

When a phase or exploratory effort becomes the “what” we are estimating, a concrete definition can be difficult – especially because at this stage (early, preliminary, before we know what is needed to be built) – it is difficult to figure out the “size” of what we want to estimate.

A key element when we want to estimate how much effort, cost or duration to allocate when estimating and R&D endeavor is to figure out the scope (what is included IN the R&D and what is not!)  One way to look at R&D projects is to look at previous “similar” completed projects as a fog-test, ball park of what your particular project might entail (assuming that there are good records of such projects at hand.)

For an R&D type of effort, consider the following:

  • What is the starting point of such an effort (is it purely a concept or wild idea of a software solution or a software and hardware solution or a service?)
  • When will you know definitively that the effort is finished (i.e., project completion criteria)?
  • How many alternatives are to be explored/presented/documented?
  • Has this type of R&D effort been done by the team/company before?
  • What is the output of the effort intended to include? (Working model/prototype, mock screens, costing, documentation of results and research approach, interviews, online research, on site visits with prospective solution vendors?)
  • Are there related efforts going on (interfacing “systems” work, other software development) that could impact the proposed solutions(?)
  • What will constitute success of this effort?

Note that for each type of effort or project identified as the “it” we want to estimate, the “construction” or development equation will be different.  This is similar to having a variety of building construction equations depending on whether one is building a hospital, renovating a school or doing a study of the environmental impact of a project on a neighborhood.

First we need to know WHAT we want to estimate (the elephant in the room), then we can begin to tackle HOW we can estimate.

Best wishes,
Carol

 

Fundamentals of Software Estimating: First See the Elephant in the Room: Part 2


This is the second in a sequence of four posts (and more to come) on BASIC software estimating concepts that address “WHAT IS IT?” we plan to estimate.

Introduction

Whenever I teach project estimating or Project Management 101 (basics) to software developers, we address the fundamental questions about what we plan to do (once called “The Triple Constraint” in project management circles):

What amazes me, is that while these are great questions that need to be answered when we do an estimate, we start out by ignoring the “Elephant in the Room” – that is, what do we mean by the “it” in the questions above.  Sure, for some people “it” may be obvious that “it” is a project, but bear with me for a minute… misunderstandings about terminology and definitions are often the source of major rework when software construction is involved.

What is “it”?

  1. “It” could be the project (and all that the term entails);
  2. “It” could be the resultant product (software and/or hardware);
  3. “It” could be a phase or exploratory R&D effort; or
  4. “It” might be something altogether different...

The question of “what is it?” we are estimating is fundamental to why IMHO (In My Humble Opinion) software projects end up being over budget, late, and out of scope.  If you don’t know definitively WHAT you are estimating, how can any possible estimate be realistic?

This post is Part 2:  “It” is the resultant Product

When the “what” we want to estimate is the time, effort, cost or scope to build a software intensive product, there are different considerations than if we are estimating a project, such as:

  • What is the product – a working, full-scale “system” (multiple interlocking pieces of software plus associated hardware, and glue code for linking it all together, and documentation) or a portion thereof?
  • Are training modules and online guides to be included as part of the product delivery?
  • Does the product include hardware, and peripherals (like printers or scanners)?
  • Will the entire product (or service) be delivered in “one fell swoop” or delivered in separate pieces?  (This could involve multiple projects that may deliver parts of the software, with later projects having to redo/enhance what was delivered in an earlier release.)
  • Do we know what the product will actually be?
  • Are there multiple stakeholders (direct users or indirect ones) whose priorities for product functionality may vary or even conflict?
  • Has a product like this been done before (i.e., do we know what all is needed such as additional software, hardware, etc.)?
  • What else is included as part of the product? (And what is excluded?)

Software intensive systems are often negotiated and estimated as concrete commodities, however, the challenge of deciding “what actually constitutes the software intensive system ” is a key component that needs to be decided before doing any estimating.

Sounds pretty basic doesn’t it:  Know what “it” is you are estimating before you begin estimating…

Unfortunately, as Peter Drucker once said

“It is important to state the obvious otherwise it may be overlooked.”

Know what you are estimating BEFORE doing an estimate… pretty fundamental don’t you agree?

Comments, brickbats, responses welcome…