Tag Archives: United States

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

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

The Most Critical Skills in the 21st Century – are they Hard or Soft?


The past few months I’ve found myself instructing a series of Leadership and Communication workshops for adult professionals across the United States, together with delivering a series of Keynote Conference addresses in Europe on similar topics.

At one particular address in Dublin, Ireland, I emphasized that the beauty of modern software development approaches (such as Kanban) is that the development team can lay bare their work pipeline and ultimately collaborate (through effective leadership and communication skills) with the business. After a series of illustrative exercises (yes, at a keynote address!), attendees by and large embraced the principles of collaboration along with the concept that we need to refrain from treating each other as “machines” at work (formulated along the lines of Margaret Wheatley‘s ideas.) By treating each other as human beings from the kickoff meeting (at least), projects can achieve resounding levels of success.

One particular conference on Quality Assurance and Testing featured not only my keynote (A Soft Skills Toolkit for Testers!) on Leadership and Communication,  but at least three others of similar slant: presentations that emphasized teamwork, respect, and collaboration.  I believe that these are essential components to the success of any project!

One key point I bring home in all of my training and keynotes is that as engineers and computer scientists, we tend to minimize the emerging importance of soft skills such as leadership and communication (I have an entire 16-piece toolkit for this) as “fluff” in favor of what we often see as superior technical “hard skills”.  As an engineer myself, I see the pitfalls of a technically competent workforce that cannot talk outside of its own niche – and many others agreed.

But, it came to fully illustration the evening after one keynote.  A group of us had gathered at a local pub to sample the local beverages when the wife of a conference chair (a science based PhD herself) approached me to comment on what she had heard about my morning keynote:

“Carol, I heard that you gave an entertaining keynote presentation today, “

she started,

“…but it was “entirely without substance.”

What she was in fact saying was that my keynote, in her and her husband’s opinion, had some redeeming entertainment value, but the lack of research-data based charts and advanced equations, rendered it “entirely without substance.”

I did suppress my inclination to applaud and say “thank you for illustrating my point so eloquently” when she said this because I realized it might be a futile discussion.  Instead, I simply smiled, thanked her for her comment, and turned back to the business and beverage at hand.

Now that I am contemplating a series of workshops for future conferences (technical software engineering and quality conferences) to continue the discussions on Leadership and Communication, it occurs to me that calling these skills “soft” may actually diminish their importance – regardless of proof that Leadership, Communication and Collaboration are some of the most important and hardest skills to teach our industry leaders in the 21st century.

What do YOU think?  Are Leadership skills (such as managing to relationships, emotional intelligence, cultural intelligence, diversity, and working with teams and people) considered more as Soft Skills or as Hard Skills (akin to programming in dot net or Java) or a mix of both?

As a technical professional – how important do you think are Leadership and Communication skills to the success of your projects?

I will be awaiting your comments!

Happy holidays!

Carol

p.s., Send me an email if you’d like to see more about the Soft Skills Toolkit for Testers presentation I did in October. I would love feedback and recommendations.

EU nations receptive to Scope Management


Greetings from Copenhagen

Bo Balstrop, Carol Dekkers, Morten Korsaa
Bo Balstrop, Carol Dekkers, Morten Korsaa

I have to confess that Europeans are much more progressive and receptive to evolutionary ideas such as northernSCOPE and formalized unit pricing ($/FP) on public tendering of IT projects than the U.S.  Just this week, I met with four different groups and presented the highlights and gains to be made from adopting formalized scope management, and I am hopeful that we (Delta Axiom of Denmark, my company Quality Plus Technologies, and 4SUM Partners of Finland) can begin to offer Certified Scope Management (CSM) training courses in Denmark in the not-too-distant future.  The approach is straight-forward and minimizes the lose/lose risk that accompanies firm fixed pricing of software projects when the requirements are not well-known.

Also interesting was the fact that those most interested in learning more about the method are not even from customer or developer groups that outsource (tender) their software development, but rather companies that do development in-house.  It wasn’t a hard sell at all – the audiences in all four presentations were receptive, open to discuss how northernSCOPE might work in their organizations, and optimistic about how it can succeed in Denmark.  After all, if we can create the demand for Certified Scope Manager (CSM) services with the public or private sectors, then training is the natural next step to create CSM’s to satisfy such demand.

Representatives from one of the nation’s largest government departments that governs taxation, the equivalent of the IRS in the US, were on-hand and expressed interest in knowing more.  I’m not sure why, aside from the “not-invented-here” characteristic (that plagues more than just the US), scope management has not raised anything more than a passing glance in the US.  With all the major expenditures on software intensive systems projects underway with our public administration and Department of Defense, together with rework figures hovering around 40%, you’d think that formalized Scope Management (aka northernSCOPE) would be of interest.  While the economy definitely plays a role to cut interest in training and consulting overall, it is still a question mark in this author’s mind why there is little interest despite ample presentations and workshops I’ve done at technology conferences throughout the US over the past few years.

No worries though… as long as some part of the world sees value in the method today – it matters not where the demand is rising.  It will be interesting to watch as more CSM’s are certified in Europe to see if it peaks any interest in my home continent.

Best wishes for healthy, productive projects.

p.s., Want to know more about northernSCOPE and the Certified Scope Manager (CSM) designation?  Email me for a copy of our northernSCOPE brochure and our CSM training information.

Carol

Share
//

TLAs, Emoticons, and other Communicata…


textingTexting has gone viral and with it has come a veritable flood of TLAs and FLAs (three-letter acronyms and four letter acronyms), shortcuts, and emoticons.  When it comes to acronyms, it’s no big surprise to us in the IT (information technology) industry – we’ve been inundated with acronyms since IT was first coined.  (I remember smiling years ago when a “senior” consultant I worked with in Telecommunications asked why we’d capitalize ‘it’.)

Most niche industries use acronyms as a communication short-cut.  But acronyms also create confusion and communication obstruction when used outside of their knowledge circle, with few exceptions.  One exception I can think of is the universal acronym is “Rx” (short form for Radix, the derivative of Prescription) — seldom is this shortcut questioned or confused.

The same cannot be said for other acronyms. Take AMA for an example… this is used variously to mean the American Medical Association, the American Marketing Association, the American Music Awards, the American Management Association, the Alberta Motor Association, and others.  So when you see the acronym AMA – what does it stand for?

acronymsI got caught in an acronym fiasco yesterday – unwittingly!  I got a call and spent an hour on the phone with a prospective client who was looking for someone with exactly my “ISO” standards experience.  (I’ve been on the US delegation to ISO software engineering standards since 1994, both as a project editor writing international standards and as a national subject matter expert.)  The client told me that her firm had recently acquired a contract to provide insurance software to ISO and she knew that they would have to comply with all necessary ISO standards.

The hour-long discussion turned out to be for naught – the ISO she was looking for was the Insurance Services Organization, not the International Standards Organization (based in Geneva Switzerland) to which my experience pertained.  In retrospect, the conversation reminded me of a scene out of the old situation-comedy “Three’s Company” (which was a weekly satire filled with double entendres!)  Here I was talking about ISO standards as they might pertain to insurance (and knowing that insurance is both state regulated and nationally regulated… AND it did seem strange that an US-based insurance software company would be retained by such an international entity.  Nonetheless, I played along…) — and the firm was looking for someone in the Insurance Standards Organization based firmly in the US.

In software development, acronyms are commonly used to name software systems – and we even joke about having acronym naming meetings whereby a team creates a seemingly sensible system name to fit into a clever acronym like “ACES” (Access Claims Eligibility System).  Ultimately, the clever long form meaning is lost once the acronym is in place, and people then only remember the acronym.

Certainly, acronyms can shorten redundant and repetitive phraseology – but they do not make sense if they introduce communication barriers.  Texting shortcuts cause the same situation – if someone has to spend extra time figuring out what you are saying, you are NOT communicating.  LOL (laugh out loud), Gr8 (great), 2morro (tomorrow), L8R (later) and other shortcuts sometimes save only a couple of keystrokes so one wonders why they would be used.  In some cases, I’ve seen writings where scholars fear the dumbing down of America through texting.  They wonder if texters will lose their ability to spell (if they knew how to do so before they started texting…)

Emoticons serve to create more casual bonding between texters.  <>():- ; and other punctuation marks serve to create emotion signals and sometimes even show up in once formal written business correspondence and emails.  With emoticons there is not as much danger in being misunderstood – rather it is the introduction of “casual” language into traditionally formal settings.

If your industry needs to create an acronym dictionary to decode the meanings of the many shortcuts in use– then things may have gone too far.  Acronyms, abbreviations and other shortcuts should enable communication — not trip it up.

To your communication success!

TTFN (ta ta for now), TTYL (talk to you later), :-).

Carol

Share