Tag Archives: Ronald Reagan

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.

Advertisements

Rework, bloody rework…


In software development as in life, Rework is a standard task… the only difference is that in software development, the problem is widely recognized and remedies are sought.  When one considers that billions of dollars are spent (invested) every year on developing new software solutions, it is easy to understand how the 40% rework statistic is UNACCEPTABLE.

When I am teaching project management workshops, I explain the seriousness of rework by stating that with statistics hovering around 40% of work is rework, it means that every Monday, Tuesday, and Wednesday, the teams work diligently on what needs to be done (that is the 60%) and then every Thursday and Friday (40%) they redo what they just did earlier in the work.  “Amazing!” you might exclaim — until you realize that the rework in everyday life can be even higher!

What causes rework in software development?  Poor upfront requirements (similar to building a house without a solid floor plan), changing needs or regulations (government or corporate changes), misunderstanding (due to a lack of knowledge), poor writing and communication (or no communication), intimidation (fear of raising issues or corrections during the building process) or a number of other reasons.  The industry has worked to fix the issues with cross-training, facilitation, and user focused approaches.

Rework in everyday life

What is “rework” in everyday life?  Here are a few examples of rework in our everyday life:

  • Going to pick up your child/partner/friend at a pre-appointed time only to discover that they are not yet ready because their needs have changed (and they did not tell you). You may have to wait (wasted time) or return at a later time;
  • Having to call/email/contact someone multiple times to follow-up and ensuring that they are doing a task they committed to do for you (and often have not);
  • Having to redo something you’ve already done because the requirements were incomplete or unclear the first time;
  • Having to redo part or all of a job because something critical (like tax rules) changed part way through the job;
  • Ending up finishing a job that someone else started (this includes getting up to speed about what they’ve done to-date and potentially learning what to do before finishing);
  • Calling/emailing/contacting a group of people to track down someone who knows the status of a job that they had originally committed to do;
  • Voice recognition system “menu games”.  Rework happens when you call your bank/utility company/cell phone provider/airline with a specific question, get stuck in the voice mail menu system, finally reach a “live body” and then the call gets cut off.  You end up having to go through all the same steps again;
  • Driving somewhere according to the directions from Google maps or Map Quest and discovering that the site was out of date with the directions. You end up redoing the last steps or driving in circles before you to stop for directions and sometimes even go back home to get new directions and have to do it all again. You end up late for an appointment (which might get canceled) or miss the entire event you had planned to attend;
  • Leaving multiple voice mail messages for your son/daughter/friend/partner and then finding out that they don’t bother to check their messages more than once a day;
  • Circular / triangulated communication:  When someone complains to another about something you have said/done/not done, and the third-party tells you (adding their own spin), it creates an extra communication path.  Now you have to talk to two people instead of the original one – it’s double trouble plus aggravation to your psyche.

All of this rework is frustrating and wastes precious heartbeats that we will never get back. It disrupts our day(s), challenges our psyche and can damage our relationships with others.  While technology has minimized some of the historical rework (e.g., waiting in the wrong place before cell phones existed), and exacerbated others (text shortcuts can cause confusion. See previous post TLA’s and other acronyms).

How much of your day is spent on Rework?  At least 40% if not more!  How often do you hear people say – “I never got anything done today!”  I do not remember people saying this when I was growing up — unless there was a baby or small child involved, yet I hear this often today.  Unproductive days so often involve other people – and we can truly only change our own behaviors.  This can compound our frustration because if it was a matter of simply doing it right the first time, most of us would learn quickly (at least the second time around).

So, what can we do to cut the rework in our own lives?

Here are a few suggestions (that work can also work in the corporate world):

  • When anyone agrees to do something (even if they are volunteers), formalize it in writing or at least, verbally.  As assignments are handed out, people will often volunteer simply because it makes them look like a team player.  And then they do not follow through.  Our word is our integrity and it is critical when we delegate or ask for volunteers that we get an explicit verbal yes or no to a commitment.  When people verbalize their commitment (and sign off in some cases), their word becomes their bond.  It also confirms explicitly what it was they committed to do.
  • Ronald Reagan said “Trust, but verify.”  We need to do the same thing and follow-up on commitments non-obtrusively (e.g., “I am just checking in with you…”) and quickly.  There is nothing worse than entrusting someone to do something and then finding out — when the project is supposed to be finished — that they have not even started. Of course, miscommunication can and does happen – and this makes it even more important to see progress early, and not just before the deadline.
  • Set a series of “milestones” where you can check the ongoing progress without micromanaging.  Only when something goes awry (in terms of schedule, scope or budget slippage) should you step in and offer your help.  This, of course depends on the dependencies for jobs you are doing – if you are awaiting something that prevents you from starting, you want to be sure that things are on track so that you don’t miss your own commitments and things end up snowballing quickly.
  • Do more yourself.  If timing makes it impossible to supervise the work, it may be easier just to do the job yourself;
  • Create backup plans.  This unfortunately is the way of the world today.  While it is rework in itself to have to create backup plans when none should be needed, it is the status quo.  When people create repeated delays, you may need to do this just to keep up your own sanity!
  • Be direct. Talk to people directly instead of hiding behind emails or voice mails to get through to people – and emphasize how important it is to communicate about reality (e.g., if someone says they need a ride at 9 pm, let them know that they need to call you by 8:30pm if the pickup time has changed).  Do not talk around people (i.e. go behind their backs) if you want to keep up good team relations.
  • Find another way. Sometimes the way things have always been done is not the best way.  Einstein said, “Insanity is doing the same thing over and over and expecting different results.” The same is true of processes where rework is typically high.  Change something in the process.

What Would Reducing Rework Mean in Your Life?

When you consider that most of us do not have enough time in our already overburdened and over-committed days, what would it mean to have 10% more time?  If we could cut rework by changing our own behaviors – would it prove to be a worthwhile cause?  Imagine if rework could be reduced 20% or even further?

What do you think can be done about rework?  What has worked for you?  I am interested in hearing what you have done to minimize your own frustrations and cut rework in your life.  Insanity (as quoted by Einstein) is doing the same thing over and over and expecting different results.

Let’s stop the insanity.

Please comment.

Carol
Share