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?

Related articles

• Trust but Verify! (klextin.wordpress.com)
• Please Do Learn How to Propose Better Solutions (smarterware.org)
• Technology: Software Developers Unite to Build Better Software (prweb.com)
• “No one hits the ground running in the world of software development, and those who say they do are…” (darkerme.com)
• 5 Common Problems in Software Development (bootstraptoday.com)
• Systems Engineering Body of Knowledge (SEBOK) (herdingcats.typepad.com)
• Why I won’t hire people who want to be the “user advocate” on the development team. (jacksonfish.com)
• Stop It! Things You Do to Destroy Trust in the Workplace (amandafnewfield.com)
• Do You Over-(e)Communicate? Use this Chart to Find Out. (captivecontent.jetmh.com)

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.

Spice Conference

Spice Conference.

Please join us for the Software Process Improvement Capability dEtermination conference!

May 29-31, 2012 Palma de Mallorca SPAIN.

Everyone welcome!

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

Spice Conference

 

Spice Conference.

How Do You "Sell" Quality?

Reblogged from Quality and Innovation:

In his March 2012 question to the ASQ Influential Voices, CEO Paul Borawski presents a question that he deals with regularly – and that industry has been challenged with for several decades:

“How do I convince senior executives (often CEOs) and public officials that quality is important and an essential strategy for–pick your ending–performance excellence, competitiveness, growth, sustainability, survival, efficiency, effectiveness?”

Read more… 522 more words

An interesting take on Quality - can you believe in 2012 we are still fighting the battle (even more with the BRIC countries taking over!) of selling quality products. Read on and comment! Carol

A Lean Journey: 10 Characteristics of a Good Measure and 7 Pitfalls to Avoid

A Lean Journey: 10 Characteristics of a Good Measure and 7 Pitfalls to Avoid.

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!)

• Requirements are the (FP) size of the problem
• FP Basics – Clear up common misconceptions
• Measuring software process part 1
• What is a Function Point?

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

Childproof your Metrics Program…

As a new parent years ago, I remember childproofing household dangers like electrical outlets, and raising adult objects above my children’s reach.  Over the years, new hazards appeared and it took planning to stay a step ahead to prevent injury or damage to innocent children.

I remembered this when I thought about what could be done to avoid software metrics failures – perhaps a form of “childproofing” could avoid a few of the dangers involved.

Software measurement is NOT rocket science (despite the claims of a few eager consultants), but neither is it child’s play.  Measurement must be properly planned or it can actually cause more damage than help!

You likely recall Tom DeMarco‘s famous “you can’t manage what you can’t measure” statement, but may not be aware of his later observation that poorly planned metrics can damage an organization.

How to “Childproof” your Metrics Program:

1. Plan a clean metrics program by following the Goal-Question-Metric (GQM) approach. By so doing, metrics are only collected when they serve a specific purpose.

2. Make sure that the measurement team understands the plan.  This will make sure that specific metrics are collected appropriately and that extraneous data are not lying around (or misinterpreted).

3. Pilot the measurement and metrics in a controlled environment before rolling it out. Train the right people to collect and analyze the metrics to make sure the intended results can be achieved.  It is far easier to see dysfunctional behavior (often unintended consequences of measurement) in a controlled environment and minimize potential damage.

4. Communicate, communicate, communicate. Be honest and specific about the project plan: resources, schedule, intended results.  Prepare management not to “shoot the messenger” when early results do not equal their expectations.

5. Limit data access to those who are skilled in data analysis (do not allow management access to raw data).  Proper data analysis and correlation is a critical success factor for any metrics program.

6. Be realistic with management about their expectations.  A program designed to meet champagne tastes (for measurement results) on a beer budget seldom succeeds.  Moreover, sometimes historical data can be collected if available, other times data are impossible to collect after the fact.

7. Recognize that wishful thinking for metrics will not disappear overnight.  Management and staff may not understand that measurement should be implemented as a project:  there will be a need for training (in metrics concepts), planning, design (measurement processes), implementation (initial data collection), training (for the program), communication, etc. As a result, people may give lip-service to the overall initiative without understanding project management is necessary.  Communication and level setting will be an ongoing process.

8. Do not allow data to get into the hands of untrained users.  Often sponsors want to “play with the data” once some measurement data is collected. Avoid the temptation to release the data to anyone who simply asks for access.

9. Do a dry run with any metrics reports before distribution.  After data analysis is done, gather a small focus group together to pilot the results.  It is far easier to address misinterpretations of a data chart with a small group than it is after a large group sees it. For example, if a productivity bar graph of projects leads viewers to the wrong conclusion, it is easy to correct the charts before damage is done.  It only takes one wrong action based on data misinterpretation (i.e., firing a team from an unproductive project when it was actually a problem of tools) to derail a metrics program.

To be effective and successful, software measurement requires planning including a consideration of the consequences (such as dysfunctional behaviors that measurement may cause). Childproofing using the above steps will help to ensure your measurement program achieves success.

Have a great week!

Carol

www.qualityplustech.com

Common-sense Leadership: Respond not react…

A big benefit to teaching leadership and communication workshops to adult professionals is continuous learning: every time I teach a class, new revelations come into focus.

One such “aha” moment (where one realizes something that may not have been obvious before) is that Leadership is really about learning to Respond to a situation or stimulus instead of automatically Reacting.  Why is this important?  Responding is the thought intensive process of actively listening, pausing, and then gathering ones “thoughts” before speaking.  Gathering of one’s thoughts involves the neocortex (center) of the brain whereby we override the reptilian (instinctual) brain and the limbic (emotion-induced) brain, and hopefully create a response less prone to immediate and autonomous reactions (based on instinct or emotion).

Considering how eastern cultures (such as Japan) seem to habitually pause before asking questions at a conference or before coming to an agreement gave me “pause” to reflect on how this practice conveys power and respect – and is one often used by practised politicians at press conferences.  This results in less “eating one’s premature words” and less damage control as opposed to when one speaks too hastily or without due thought.

This is a common-sense tip on how to practice better leadership in your own workplace no matter your position:  remember and practice active listening (if you are thinking of what you are going to say – you are not listening!), pausing, gathering your thoughts (and perhaps even saying “please give me 15 seconds to gather my thoughts”) and then thoughtfully responding.

Food for thought – what do you think?  Could this be helpful in your workplace?

Carol