Tag Archives: CSM

IFPUG (News) Beyond MetricViews – FP for Agile / Iterative S/W Dev


With the support of QSM, Inc., I wrote and published this article on a new area of the International Function Point Users Group (IFPUG) website called “Beyond MetricViews.”

While the IFPUG already had published guidelines in this area, the key points to this article include:

  • If you want to measure productivity (or anything else) consistently across two or more software development projects – where each was developed using a different approach (i.e., waterfall vs. agile) – one must be consistent in the definition and application of the measures (and metrics);
  • Function points are defined in terms of elementary processes and agile methodologies deliver such functions iteratively (not complete in one iteration) – posing challenges to the uninitiated;
  • Regardless of whether you measure productivity, defect density (quality), costs or other aspect of software delivery – it is critical to do an “apples to apples” comparison.

Here’s the article (click on the image) for your interest.  (You can also visit the blog at www.qsm.com for details.)

ifpug

Comments and feedback is appreciated!


As part of ongoing writings on software sizing and function point analysis, I recently posted the following article on the QSM blog.  Enjoy!

FP as mousetrap

Latest installment of “Ask Carol: Sizing Alternatives when Cost is an Issue”


Happy new year 2014!

I present you with the latest installment of the Software Professional’s advice column I pen for QSM, Inc. called “Dear Carol” (click here also for the direct link)

Ask carol - Sizing alternatives when cost is an issue

Enjoy!  Comments are always appreciated and welcome. What do you think of this 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

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

Walking on Eggshells – a Normal part of Business?


We have all been there – walking on eggshells to avoid outbursts from  a boss, co-worker, or client.  So we skirt the issue, pretend the bad behavior doesn’t exist, ignore the problem, and spend extra time planning how to present an issue so that the person in question doesn’t explode.

While I know that this type of behavior is rampant in business (I’ve experienced it more than once!) – it has serious (and expensive) consequences in the IT industry.  The repercussions stemming from having to “walk on eggshells” to avoid the potential wrath ranges from minor  “oversights” to full scale project failure.

The Challenger disaster is one such failure where group-think and avoidance of conflict ended up costing lives and millions of dollars.  A video chronicling the group think behavior depicts the group-think behavior and steps are taken in companies to address such behaviors. This is all good.

The Walking on Eggshells “syndrome”

Aside from the pressures of group think that encourages teams to conform and cooperate with a single mindset, the “walking on eggshells” syndrome is seldom documented or even discussed.

We all know at least one offender in our workplace!  The offending person may be a narcissist, a control freak, a bully or just plain immature. No matter the clinical diagnosis, our boardrooms and our production labs suffer greatly from their presence.

How much time and money could be saved by confronting these people and addressing the cost of their ‘verbal diarrhea’? Here’s the type of situations I mean:

  • Not raising issues:  “How can we possibly bring up the design flaw for this software now?  The project sponsor will yell and rant if the project is late. Remember how he “freaked out” at the status meeting last month?  Keep going and we’ll address this as an enhancement.”  Cost: could be significant.
  • Cutting corners: “There is no way we can finish the project within the approved budget.  We had no idea that xxx would be so complex, but the steering committee will fire us if we ask for more money. Let’s just cut testing so we can finish the project.”  Cost: could be critical if public safety is at stake.
  • Perpetuating the myth that project plans are right:  “The project plan was based on incomplete data that seemed right six months ago. Now we know more, but with a fixed budget and schedule, we’re stuck. The client will explode if we bring up that the plans were flawed. Let’s just do what we can.” Cost: Corporate learning will never happen (Einstein: insanity is doing the same things over and over and expecting different results.)
  • Skirting accountability: “We messed up on the schedule because we had to program that module 3 times.  I couldn’t understand what they wanted until this time, but we can’t tell Bob because you know how he gets.  I hate it when he yells in a staff meeting.” Cost: could be significant to minor.
  • Wasting time and money: “This project is doomed – the users told us they won’t use the system even if we finish it. The rationale and vision for the project are no longer correct (it’s a dog!) but if we tell the boss about it, you know how she will blame us. I don’t think it is even worth trying to explain it.  Just keep going.”  Cost:  priceless – time and money could be better spent on REAL work!

What a colossal waste of time, money, energy, and morale “walking on eggshells” is to a business!  It is not an easy situation to fix or address – especially when we are talking about people in power who behave badly.

Walking on eggshells should never be part of the way of doing business!  What is the solution?

If YOU were the king of your IT kingdom, what would YOU do?  I’ll publish a summary of responses – add your comments below – or send them privately to me by email to dekkers (at) qualityplustech (dot) com.

Have a productive week!

Carol

Function Points for Mere Mortals… Part 1: NOT Rocket Science


Does this sound familiar?  Your project completed under the “radar” (no major mishaps) and management wants more, more, more!  As part of the quest for faster, better, cheaper, someone in management decides that you ought to be reporting metrics and suggests that everything be built around “Function Points.”  A sponsor (the VP) appoints you the project manager for the Metrics Implementation (aka Function Points) and everything you thought you knew simply vanishes as soon as he walks out the door.

The Internet is Schizophrenic

If you are like most people, your first step is to ask your network (social media, peers, friends, etc.) what these “function points” are all about.  I have written about the simplicity and straight forward nature of Function Points for over 15 years (see downloadable articles below) and yet confusion still abounds in the IT industry!

As you begin to research the topic, thousands of internet links come up offering “Function” or “Points” or variations thereof. Once you find “Function+Points”, the filtered results create confusion as some sources elevate function points to a scientific treatise with the complexity to match.  This is simply not the case – Function Points are a unit of measure used to size the “functionality” of a piece of software that can be used to normalize measurement.  While certain consultants want to elevate Function Points to a mystical religion where only a handful of elders can do a count – this is not the case at all.  (These consultants seek to create an exclusive club where you have to hire them to count – this is utter hogwash!)

This is the point of this post:

Part 1: FUNCTION POINTS ARE not Rocket Science

As I mentioned, I and others publish (and continue to publish) articles and books about function points, yet software metrics is not yet a mainstream practice.  Confusion, disdain, and even downright misinformation abounds about this simple concept – creating a size of software that can be used as a basis (like square feet in a building) for estimating.  This is not Rocket Science!

In Project Management terminology, Function Points are the size of the overall work product for a project whose product is Software.  The WBS (work breakdown structure) for a software project includes all of the software deliverables, and function points is one way of sizing the functionality of the delivered software.  While there are additional things to be considered when doing a project estimate (such as quality, how the software will be built, critical path, resource constraints, risks, etc.) but a fundamental item is the scope.

Function points provides us with a measure of the scope of the software project.  Furthermore, the fundamentals of function points or FP (like the fundamentals of measuring square feet) have not changed in 15 years and counting methods are stable!  Certainly how we implement software has changed, but the functionality and scope have not – so why have FP not become maintream?

Capers Jones published a primer on function points (“Sizing up Software“)  in the December 1998 issue of Scientific American for which the abstract is below:

Modern society has become increasingly reliant on software–and thankfully so. Computer programs routinely execute operations that would be extraordinarily laborious for an unaided person– handling payrolls, recording bank transactions, shuffling airline reservations. They can also complete tasks that are beyond human abilities–for example, searching through massive amounts of information on the Internet.

Yet for all its importance, software is an intangible quantity that has been devilishly tricky to measure. Exactly how should people determine the size of software?

Want more basic information?  Here are four downloadable articles (PDF format) to further introduce you to function points:  (The content is still timely!)

Long and short oN function points? 

They are NOT rocket science and can be fundamental building blocks to a successful software estimating and metrics program.

Was this post useful?  Let me know!

Stay tuned for Part 2:  Getting started with Function Point basics.

Have a productive week!

Carol

Whose job is IT anyways?


The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share

The importance of Being There (at work)!


Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share