Tag Archives: project management

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

Advertisements

If IT’s important – get a second (or third) opinion!


I’d like to share with you my latest  post on the QSM (Quantitative Software Management) blog – let me know what you think!

-Carol

1st in the series

1st in my new series – here’s the URL:

http://www.qsm.com/blog/2013/ask-carol-if-its-important-get-second-opinion

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…

 

Fundamentals of Software Estimating: First see the Elephant in the Room- part 1


This is the first 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):

  • How big is it? (Scope management)
  • How much will it cost to build? (Cost estimating and budgets)
  • How long will it take to build? (Scheduling)
  • How good does it need to be? (Quality)

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.

elephantWhat 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 1:  “It” is a project

The concept of a “project” is the basis of Project Management 101 (per the Project Management Institute‘s formal PM Body of Knowledge: PMBOK®).

When I taught project management for a major government agency overseeing billions of dollars of software development, it amazed me to find out that many unofficial, self-appointed “project managers” accepted the notion that  a project could be an amorphous concept with a jello-like scope, undefined start/end points (let alone the idea of acceptance criteria that would define when a project is “done”), sketchy objectives, that could go on for years without delivering results.  For many, the end of the project was a often a moving target because new functions were routinely added during construction or “substituted” for things that were no longer needed. Such projects run out of control with schedules that go on forever, a scope that remains ambiguous and ever growing, and budgets that are essentially buckets of money.

Some projects started with an idea (no one could remember why) and as long as it “stayed in the green box”  (meaning that it didn’t raise the ire of management or be outside of acceptable metric limits) it was a “good project.”  The prevailing idea of a project budget was “five people working full time on this stuff until we’re done” and the schedule was “we thought we’d be done by now, but management keeps adding more stuff to the pile of things they want in the system.”

As an engineer, I often compare software development to building construction – with the difference being that software development often starts without “sealed engineering drawings” or the equivalent (formal plans) and either gets canceled along the way or goes on until someone says “stop.”

The Project Management Institute (PMI) defines a project in its PMBOK® 4th Edition as:

A temporary endeavor undertaken to create a Unique product, service or result.

So, if we are estimating a PROJECT, we must minimally be able to define:

  • What is the scope of the project:  Will it include a full lifecycle (i.e., from concept definition and requirements through to working installation of software for the first user?) What is the final result (a product, a concept, a service) and what are the functions to be included?
  • Who (the stakeholders), what (as above), when (how will we know it is done?), where, and why (what’s the objective?)  Note that HOW the project is to be done is outside the definition of the project.
  • What is included (and even more important sometimes – what is NOT included) and what are the start and stop points?  What (explicitly) is outside the boundaries of the project (such as training; corporate rollout; multiple languages; etc.)

Once you’ve defined that “it” is a project that you want to estimate, and have defined what constitutes said project as outlined above, make sure to write them down.  Once you’ve got these minimal things documented, you are ready to at least begin to think about how to estimate the items in the original list I presented at the top of this post (how big, how long, how much, how good.)

For more information and definitions about “Projects” refer to www.pmi.org (The official site of the Project Management Institute.)

Stay tuned for part two: If “it” is a product.

Estimating Before Requirements with Function Points and Other Metrics… Webinar Replay


On June 7, 2012, I conducted an hour-long webinar on “Estimating Before Requirements with Function Points and Other Metrics” before a worldwide audience spanning a myriad of software development specialties/industries and across many countries.

In the event that you missed the live webinar or would like to listen/view the replay, it is available (at no charge) at http://www.qsm.com/Webinars/Estimating-before-Requirements

At the end of the webinar, I offered to send attendees several papers (also downloadable from this link) as well as a Scope Management primer.  If you are interested, please send an email to me at: dekkers (at) qualityplustech (dot) com.

Let me know what you think of the concepts and the webinar!

Carol

Trust and Verify are the (IT) Elephants in the room


As a party involved in some aspect of software development, why do you think projects are so hard?  Millions of dollars in research work to solve this question, with the result being new models, agile approaches and standards, all intended to streamline software development.

What do you think is the core reason for project success or failure?  Is it the people, process, requirements, budgets, schedule, personalities, the creative process or some combination?

Sure, IT (information technology) is a relatively new industry, plagued by technology advances at the speed of light, industries of customers and users who don’t know what they want, budgets are preset, schedules are imposed, scope is elusive, and, ultimately computer scientists and customers still speak their own language.  Some people argue that it boils down to communication (especially poor communication).  After all, isn’t communication the root cause of all wars, disputes, divorces, broken negotiations, and failed software projects?

I disagree.

I believe that TRUST and VERIFY are THE TWO most important factors in software development

These two elements are the IT elements in the room (so to speak!) I could be wrong, but it seems like the commonly cited factors (including communication) are simply symptoms of the elephants in the room – and no one is willing to talk about them.  Instead, we bring in new methodologies, new tools intended to bring customers and suppliers together, new approaches, and new standards – and all of these skirt the major issues: TRUST and VERIFY.

Why are these so critical?

Trust is the difference between negotiation and partnership – trust implies confidence,  a willingness to believe in (an)other, the assurance that your position and interests are protected, and the rationale that when life changes, the other party will understand and work with you. A partnership means that there is an agreement to trust in a second party and to give trust in return.  Trust is essential in software development.

BUT… many a contract and agreement have gone wrong with blind trust, and that is why VERIFY is as important as trust. Verify means to use due diligence to make sure that the trust is grounded in fact by using knowledge, history, and past performance as the basis.  Verify grounds trust, yet allows it to grow.

President Ronald Reagan coined the phrase “Trust, but Verify” – but I believe it is better stated as “Trust and Verify” because the two reinforce each other.  This also suggests the saying:  “Fool me Once, Shame on You… Fool me Twice, Shame on Me.”

Proof that Trust and Verify are the Elephants in the Room

Software development has a history of dysfunctional behavior built on ignoring that Trust and Verify are key issues. It is easier for both the business (customers) and the engineers (suppliers) to pretend that they trust each other than address the issues once and for all.  To admit to a lack of trust is tantamount to declaring war and accusing your “partners” of espionage.  It simply is not done in the polite company of corporate boardrooms.  And so we do the following:

  • Fixed price budgets are set before requirements are even known because the business wants to lower their risk (and mistrust);
  • Software development companies “pad” their estimates with generous margins to decrease their risk that the business doesn’t know what they want (classic mistrust);
  • Deadlines are imposed by the business based on gut-feel or contrived “drop dead” dates to keep the suppliers on track;
  • Project scope is mistakenly expressed in terms of dollars or effort (lagging metrics) instead of objective sizing (leading metrics);
  • Statements like “IT would be so much easier if we didn’t have to deal with users” are common;
  • Games like doubling the project estimate because the business will chop it in half become standard;
  • Unrealistic project budgets and schedules are agreed to to keep the business;
  • Neither side is happy about all the project meetings (lies, more promises, and disappointment).

Is IT doomed?

Trust is a critical component of any successful relationship involving humans (one might argue that it is also critical when pets are involved) – but so too is being confident in that trust (verify).  Several promising approaches address trust issues head on, and provide project metrics along the way to ensure that the trust remains.

One such approach is Kanban (the subject of this week’s Lean Software and Systems Development conference LSSC12 in Boston, MA).

Kanban for software and systems development was formalized by David Anderson and has been distilled into a collaborative set of practices that allow the business and software developers to be transparent about software development work – every step of the way.  Project work is prioritized and pulled in to be worked on only as the volume and pace (velocity) of the pipeline can accommodate.  Rather than having the business demand that more work be done faster, cheaper and better than is humanly possible (classic mistrust that the suppliers are not working efficiently), in Kanban, the business works collaboratively with the developers to manage (and gauge) what is possible to do and the pipeline delivers more than anticipated.  Trust and verify in action.

Another promising approach is Scope Management (supported by a body of knowledge and a European based certification) – a collaborative approach whereby software development effort is done based on “unit pricing”.  Rather than entertaining firm, fixed price, lose-lose (!!!) contracts where the business wants minimum price/maximum value and the supplier need to curtail changes to deliver within the fixed price (and not lose their shirts), unit pricing actually splits a project into known components can are priced similarly to how home construction can be priced by square foot and landscaping priced by the number of trees.

In Scope Management (see www.qualityplustech.com and www.fisma.fi for more details or send me an email and I’ll send you articles), the business retains the right to make changes and keep the reins on the budget and project progress and the supplier gets paid for the work that the business directs to be done.  Project metrics and progress metrics are a key component in the delivery process.  Again TRUST and VERIFY are key components to this approach.

What do you think? 

Please comment and share your opinion – are TRUST and VERIFY the IT elephants in the rooms at your company?

P.s., Don’t forget to sign up for the SPICE Users Group 2012 conference in 2 weeks in Palma de Mallorca, Spain. See www.spiceconference.com for details!  I’m doing a 1/2 day SCOPE MANAGEMENT tutorial on Tuesday May 29, 2012.

Whats behind Project Success: Process or People?


Depending on who or what you read, most software and systems projects (over 50%) end up as unsuccessful/failures:  over budget, late, and/or fail to meet the user needs.  As a worldwide phenomenon, studies continue to expound on why projects fail (poor requirements, underfunding, overoptimistic estimates, unreasonable schedules, lack of management commitment, etc.) but few studies focus on what it takes for projects to succeed.

What do you think makes a project (of any kind) successful?  What is more important to project success:

1. The processes involved (e.g., formal project management, standards, shortened development life cycles, agility…); or

2. The people involved (e.g., the right team makeup, a good mix of skills, a motivated workforce, engaged users); or

3. Trust (e.g., collaboration rather than negotiation between customers and suppliers, reliance, cooperative teamwork; communication); or

4. Something else (e.g., other factors such as CMMI, tool sets, unlimited budgets, Steve Jobs on the team, …); or

5. Some “magical” combination of the above; or

6. None of these?

Across industries and across the world, is there a difference in what makes a project successful?  Are there certain factors that predispose a project for success (or failure?)

What do YOU think?  Inquiring minds are interested in hearing from you… (please post a comment or send me a private email to dekkers (at) qualityplustech (dot) com).

Thank you!
Carol