Category Archives: Articles

Superheroes in IT, come down to earth…

Are you a technology superhero?  Then you might want to read this (and even comment!)

Information technology is a widely misunderstood part of business:  executives view us as a necessary evil, yet do not understand  IT is an investment.  As technology professionals, we lament our treatment as suppliers (or even servants) instead of business partners, and spin our wheels trying to prove that we add value to the business. What we fail to see is that we unwittingly contribute to the dysfunction with a superiority complex that we project on the business.

We view ourselves as technology superheroes, while the rest of the world sees us as overpaid intellectuals lacking in social skills.  There is no right or wrong here, just misunderstanding on both sides of the relationship.

The Superhero World

As software engineers, it is hard to imagine that the world thinks any differently than we do.  We take for granted how we learn, digest and embrace new concepts, so much so that we assume it is universal.  Certainly, we recognize genetic individuality, but we assume thought patterns are common. When we assimilate new ideas easily, we assume that others can too. We reinforce our beliefs by seeing co-workers behaving the same as we do.

This is a major issue in IT and engineering (and other professions as well) where success hinges on clear communication and a shared understanding of business needs. As software engineers and product developers, we live in an insulated world – one laden with technical terms and concepts, and life as we know it can be exciting!  We are the superheroes in IT – we use Kanban, Lean, and Agile to get close to our customers and we develop advanced software solutions that make the world better in a single bound.  Or so we think…

The world would be perfect if we could concentrate on doing what we do best – building great software solutions – without interference from the outside world. The problem is that we have to deal with “mere mortals” in business, and for some reason we are simply not on the same page. Herein lies the problem:  our assumption that the world thinks the same way that we do.

As superheroes in the IT world, we ARE different, but we need to function in the real world.  We are addicted to technology but others are not… so who has the problem and what can we do about it?

First steps…

The first step in solving any problem is to admit that it exists and take responsibility for our part.  This means taking a hard look at our role and what we can do to change the dynamics of the business / IT relationship.

Here are a few ways that we can take responsibility for improving the relationship:

  • Realize that the way we look at the world is not universal. As software engineers our passion for technology is hardwired, just as others are hardwired with passion about banking or marketing. My professors (and maybe yours) taught that everyone aspires to engineering and computer science, but few can make it, and this created an elitist view of the world.  I now know how this attitude projected a sense of superiority and entitlement to special respect that is simply, undeserved. Recognizing these differences is the first step to humility and true communication.
  • It might sound impossible but… technology IS intimidating.  Moreover, the subject can be boring to others. The world does not share our zest for IT English – we may be superheroes when it comes to creating technology solutions, but that does not make it interesting to others. While it might seem like “dumbing down” when we translate IT English into business English, there is no other way.  If we continue to talk our talk without consideration of others – well, we sound unintelligible.  (Just watch an episode of the TV show “Big Bang Theory” for a glimpse of how techies seem to the world).
  • There is no base level of idiocy. Many technical professionals believe that there is a base level of knowledge idiocy.  In IT, we dismiss anyone as an idiot whose technical knowledge is below this “line” and then treat him/her as a lesser being. While we do not necessarily do this consciously, it comes across in the way we talk down to non-technical people.  Sure, doctors do this, lawyers do this, and software engineers do this, but it does not promote good relationships on projects. The sooner you realize that your basic level of knowledge (such as knowing about the software development life cycle or communication protocols) is above the general population, the better off you will be.  While you and I might be aghast to realize how little most people know about software concepts, they do lead successful and productive lives without this knowledge.  We are the idiots if we cannot translate IT English so our customers can understand, not the other way around.
  • Read outside your world. If we want to understand how our customers think, we need to explore outside the world of technology. Find out what journals your customers read, and pick up a copy. When you start to understand what your customer’s world is all about, you can start to solve their problems.
  • Accept the world that is. Engineers are known the world over as being great at technology and poor at communication.  Instead of denying this fact and defending ourselves, we ought to accept it, improve it, and move forward.  Communication and soft skills can be learned, but we first have to admit that we need help.  I know many software engineers who behave as ostriches by burying their heads in their work and avoiding customer contact.  Why not accept the world as it is and improve on it through education?  Ignorance is bliss except when it comes to communication – and the good news is that communication can be learned.

If we want to garner respect for the IT superheroes among us, we need to come down to earth and live among the “mere mortals” (non-IT).  Only then can IT save the world.

What do you think?  Agree or disagree? Comments?

Carol

Share
//


Separated by a common language... IT English is different

I am not a stupid person, but I simply cannot keep up with all the new information technology (IT) terminology!

I know that every industry has acronyms and terms, but it seems that IT artifactis unique: every time a new methodology comes in, English words are redefined.  Today, IT English is expanding.

For example IT English uses Scrum (but not for rugby), Ruby (not for birthstones), Java (without caffeine), and Artifacts (but not from Egypt).  Certainly, English English is different from American English and Australian English, but IT English is a dialect unto itself.

If I, as an engineer with experience in IT, am daunted by the ever-changing IT English, how much worse is it for laypersons who work on software projects?  It can be intimidating.

I read an “introductory article” written by an IT colleague today and had to read and re-read it several times before I gave up. Despite visual aids and process flows, I felt I needed a geek-to-English dictionary to make sense of it.  (Yes, it was written in English.)

Most of us are not bilingual, so it should be no surprise that many technology professionals only know IT English. In fact, some do not even realize that there are other English dialects. When engineers find a new way to do things, you can expect a flurry of new acronyms and variations on IT English.

This happened with “waterfall”, client/server, web development, agile, lean, and Kanban. Once you understand that old words get new meanings, it all makes sense, but it is a learning curve every time.

Do you know that everyone (outside of IT) asks

Why can’t IT just speak English?

Outside IT, it’s no mystery why software projects fail (to meet user needs).  Just when users and the business learn enough IT English (technology) words to converse, a new method comes in and the dialect changes.

In my post earlier this week (IT’s all about the people, stupid), I touched on the need for “soft skills” in technology, and mentioned the communication factor.  Soft skills or EQ (emotional intelligence quotient) covers more than communication (such as empathy, consideration, mutual respect, cultural sensitivity, communication, and a host of other people skills), but communication is the linchpin.

My first IT English “encounter”

I’ll never forget my first engineering job in Alberta, Canada working for a pipeline engineering company. During the first week, a colleague suggested that I should “sign on” to the mainframe.  I gave him that “are you nuts – why would I want to do that and have to call IT?” look and walked away shaking my head. No one in his/her right mind would purposely “interface” with IT unnecessarily.

monitorAs luck would have it, I found myself working in IT a year later. On my first day, I had to sign on and predictably, the system crashed within an hour.  I became the network operations’ comic relief when they asked me my terminal address and I responded that I was on the eighth floor. Over muffled laughter, they told me they needed the 16-digit number on the side of my terminal (monitor)… and added that they were also on the 8th floor.

I had no idea that my English fluency would be so tested in IT.  While I knew that English is the language that separates so many across countries, I didn’t know it also was true with IT.

What is the solution for IT English?

misunderstandIf we truly want to make progress with technology, we need to recognize the walls that IT English puts up around us.  It’s not enough to know that there are walls and to converse with each other – we need to care about the misunderstanding that arises whenever we redefine English words and expect the world to understand.

IT needs to stop talking in acronyms and start translating our IT  English into English English or American English (a dictionary or savvy translator can help) so that when we talk technology, others will listen.

That is, if we truly want to communicate with the business.  It reminds menapoleon of the English Channel Tunnel (Chunnel) project:  did you know that it was originally started by Napoleon over a hundred years earlier?  The project stopped when Napoleon realized that the tunnel would not be a one-way deal…

What do you think? Am I being too cynical about IT?  Is there hope for IT English to become mainstream or vice versa?

(Fade to black with the strains of Dr. Doolittle’s “I want to talk to the animals…” )

Have a productive week!

Carol

P.s. Don’t forget to register for the #LSSC11 FREE Webinar series – Feb. 2, 2011 (noon-1pm PST — 3 -4pm EST!)  Session #1: INTRODUCTION TO KANBAN with Janice Linden-Reed. Register here: http://tinyurl.com/69ae36w

Share

IT's all about the People, Stupid...

(Note to self: Remember Mark Twain’s quote – If I had more time, I’d have written less…)

It seems apropos to use this headline to illustrate soft skills’ importance in software development (the 1992 Clinton presidential campaign coined the originalIt’s the economy, stupid).

What do you think?  Do technology skills trump people skills in IT (this was the traditional engineering approach)?  I believe that people skills are at least as important – if not more important – than the hard methodology or coding skills.

I believe that the lack of people skills are at the root of several issues in IT today, unless you work on projects for unknown customers, such as the story this week in the NY Times: Can Apple Find More Hits without its Tastemaker:

Steve JobsShortly before the iPad tablet went on sale last year, Steven P. Jobs showed off Apple’s latest creation to a small group of journalists. One asked what consumer and market research Apple had done to guide the development of the new product.

None,” Mr. Jobs replied. “It isn’t the consumers’ job to know what they want.”

“IT would be easier without the people”

One of my first MIS projects as a programmer was memorable for two reasons:

  1. It was the first time I heard the phrase above; and
  2. My boss made a deal to get sponsor sign-off on requirements by promising that he (the sponsor) could change anything down the road that he didn’t understand.

It was a project from hell (change running rampant) and it was the first time I truly realized that we go into computer science and engineering because we are good at technical subjects, not communication.  Back then, waterfall development was essentially done “over the fence” with the business throwing the requirements over to us, we doing the design and build, and then us throwing the finished software back to the business for testing. More often than not, our “perfect” software missed the mark in terms of functionality, and was typically late and over budget.

Certainly much has changed with the new approaches – can you imagine software development without regular end-user contact?

How much rework is people-based?

CalendarDoes it surprise you to learn that software development is fraught with rework – in traditional settings it is close to 40%?  This means – literally – that we do great work every Monday, Tuesday and Wednesday, and then get to redo it all every Thursday and Friday.

Thanks to Kanban, Agile, Lean, Scrum and other customer-focused methods, our industry is getting a lot better at reducing rework, and at identifying non-productive wait times/delays from customers and others. We are also better at knowing how to deliver incrementally to customer needs. Augmenting the new approaches are job roles specifically tasked with customer facing such as business analysts, project managers and user advocates or scope managers. Some might argue that these roles are inconsistent (or even counterproductive) with Lean or Agile approaches, but that is the topic of a future post.

Regardless of approach, however, engineers and computer scientists are no fundamentally different today than they were in the days when I attended college.  We choose these professions because we love math, science and technology, have a reasonably high-IQ, and want to make a difference in the future of the world (at least that is my excuse!)  People do not go into engineering or computer science for the people skills.

Sure, there is a growing recognition that both engineers and computer scientists must have good people skills when they enter the workforce, however, soft skills training is still secondary.  Soft skills remain some of the most elusive and necessary skills in software and systems development.

(Side note: at an SEPG conference several years ago, research showed a high concentration of early onset autism/Asberger’s syndrome among Silicon Valley’s professionals.  For SEPG, this was a very controversial session that led t interesting results: 1. developers who already felt socially inept wondered just how inept they might be; and 2. others took careful notes so that they could report people they didn’t get along with to HR with the suspicion that they might be autistic. Presenters were careful to say that this research was inconclusive and PRELIMINARY.)

In my experience software engineers score high marks in technical areas but fall short in communication skills because:

  • they do not realize that they are poor communicators (their co-workers and friends understand them);
  • they see themselves as superior in intelligence to non-IT’ers, which can lead to condescending behavior (“what do you mean that you don’t know what these acronyms mean?”
  • they do not realize that both the sender and receiver are part of the communication loop (as in “I understand perfectly, it’s the business who has a problem”);
  • they value technical proficiency over soft skills proficiency (if something is not complex and technical, where is the value?); and
  • they have not taken soft skills training aside from a presentation skills course in college.

What did I miss on this list?

What are soft skills?

While I hate to quote Wikipedia, it has a good definition for soft skills (better than dictionary.com):

Soft skills is a sociological term relating to a person’s “EQ” (Emotional Intelligence Quotient), the cluster of personality traits, social graces, communication, language, personal habits, friendliness, and optimism that characterize relationships with other people. Soft skills complement hard skills (part of a person’s IQ), which are the occupational requirements of a job and many other activities.

Soft Skills are behavioral competencies. Also known as Interpersonal Skills, or people skills, they include proficiencies such as communication skills, conflict resolution and negotiation, personal effectiveness, creative problem solving, strategic thinking, team building, influencing skills and selling skills, to name a few.

How many of these skills are explicitly taught as part of Scrum, Kanban, Lean or Agile training?  (In fairness, they were never taught in waterfall or structured analysis classes.) I know that there is at least recognition of soft skills importance with newer customer-centric methods, and I believe there is still a gap.

Are you better at presenting and communicating with users doing  Kanban or Scrum than you would be if you were involved in waterfall development?

As our industry has learned better ways of developing software-intensivScalee systems, neither our business partners nor we are well skilled in soft skills.  Accountants, marketing majors, doctors, actuaries, and human resources can also suffer from too much IQ and not enough EQ.  So, who is responsible for making sure that business outcomes, funding levels, and trust are present in the IT/Business partnership?  Both sides are definitely responsible for their own part to make things better.

On the development side, we need to recognize that prowess in terms of effective communication, knowledge transfer, people networking, facilitation, cultural awareness, etc. do not come by osmosis – we need soft skills practice and training.  When we are experts at both the hard and soft skills, our entire industry will gain – and so will our business partners.

How are your soft skills?  Here is a quick quiz: http://www.bettersoftskills.com/quiz/

Soft skills workshops?

It is easy to blame misunderstanding, lack of technical prowess, and poor communication on users, but IT has yet to recognize that IT’s not about the business; IT is all about the people.

Are you interested in attending a dedicated session on soft skills for technical professionals?  Drop me an email for information on my upcoming one-day IT’s all about the People workshop.

Have a productive week!

Carol


Share
//

There's no time for "One of these days is none of these days" in IT

Let’s face it

– an investment in software development can be one of the most expensive and medieval timesrisk-laden endeavors a corporation can make, especially when requirements volatility and uncertainty are part of the mix.  In medieval times (of software development this would be pre-2000), customers and developers often jostled over requirements and clashed on issues of flexibility during strict waterfall development.  Then after months of protracted requirements discovery, the construction process would be frequently disrupted by “unanticipated change”.

Fortunately, for everyone involved, innovative techniques flexible to change and offering shorter, more iterative delivery cycles emerged.  Today, a myriad of choices exist that embrace flexibility and deliver high-quality software more effectively and efficiently than ever thanks to agile, XP, scrum, CMMI, project management and other concepts.  Additionally, methods that worked well in other industries have been adapted and tailored for use in IT (six sigma, kaizen, TQM, theory of constraints, just-in-time, Kanban, etc.).

A few of the most fundamental

yet simple concepts of Lean/Kanban/Just-in-Time development (and other methods) include minimizing waste (non-value added activities), removing roadblocks/delays and limiting work-in-progress (WIP).

If we consider software development as a “pipeline” of constant flowing work packets, any unresolved blockages can end up clogging the entire system.  As such, when life intervenes (as it always does) to interrupt or delay the flow of a work packet, approaches such as Kanban  highlight potential blockages before they clog the entire flow.  Teams can then identify remedial actions so that the right work is done at the right time, freeing up resources to concentrate on work where they can be highly productive.  Moreover, while waterfall development commonly fills the pipeline beyond capacity (without realizing it), Kanban limits the input stream to match the available capacity.  Once work is actively in the pipe, a critical delay (“one of these days…”) signals trouble and work can be removed (“none of these days”) until such time as it can be productively worked again or triaged to prevent ongoing delays.  If we are serious about reducing waste (non-value added activity) or delays, IT should never tolerate proverbial “one of these days is none of these days” delays in process.

Unexpected events and delays are a natural part of life (and software development).  The difference with Kanban and JIT is that there is a conscious response to bottlenecks and work stoppage rather than panic or blame reactions (OMG!  What do we do now?) typical of waterfall development.

Can Kanban co-exist with Agile development?

I believe so (and perhaps this is the attitude of a naive believer in both).  Can Kanban co-exist with Waterfall development? Again, I believe the answer is yes.  What do you think?

Don’t forget to register (and tell your management to register!) for the upcoming FREE knowledge webinar on January 18, 2011 featuring

LSSC11 Chairperson, Kanban expert and Author:
David Anderson

on Lean Decision Making, January 18, 2011 from noon – 1 pm Pacific Standard Time (3-4pm Eastern Standard Time). Here’s what this FREE webinar is all about:

Lean thinking assumes it is economically better to build a culture of trust in an organization of empowered individuals to accelerate decision-making and shorten lead times than to mitigate risk with bureaucracy and delayed delivery. Understand the economic model controlling the forces of risk, uncertainty, business value, quality, cost and schedule that affect decision-making and process policy setting. This webinar will show how lean thinking can translate into process and policy decisions more closely aligned with business goals.

Register today to reserve your webinar place!

Why not make 2011 the year that you make a difference in the world of software development by getting up to speed on Lean approaches?  Plan to join us 3-6 May 2011 in Long Beach, CA, USA for the Lean Software and Systems conference (acronym LSSC11) – register today!

Carol
Share

What Goes Around Comes Around in S/W Development... Let's minimize the rework with Lean!

If you don’t have time to do it right, when will you have the time to do it over? (aka Do it Right the First Time).  There has to be a better way (and there is)!

Rework… what a waste (literally)!

Rework is one of the most frustrating aspects of software and systems delivery, especially when you consider that over 40% of IT development effort is spent doing rework (stats hover around 45% according to published reports from the Department of Defense).  Why is rework so high in software development?  There are many reasons including incomplete or unclear requirements, customer changes (since the beginning of the project), and elongated timelines.  Can you imagine what our life would be like if every industry was plagued by this amount of rework?

  • Construction would take two to three times as long to complete (imagine construction without sealed engineering drawings!)
  • Medical surgeries would mean that patients would have to endure multiple operations to get the original job done properly (I can hear the lawyers applauding already)
  • Clothing manufacturers would have to double their prices because of waste due to improperly cut or sewn garments

Few other industries would tolerate this level of rework…  yet IT not only tolerates rework (in the hope of delivering a product that achieves high customer satisfaction), but most projects end up late, over-budget, and delivering unnecessary or incorrect functionality.  Often projects are rushed through when schedule crunches and rework overwhelms them, or functionality or quality is sacrificed to finish on time.  In either case, results include inadequate software product releases, with costly follow-on maintenance to correct poor quality or product deficiencies.

When Phillip Crosby wrote his award-winning book “Quality Is Free”, many professionals mistakenly thought the title meant that there is no cost to building quality into product development. Today we know that Crosby meant that quality pays for itself in the long run – and ultimately reduces product development costs.  Unfortunately, the idea of doing things right the first time is still a pervasive challenge in IT – and not all the blame lies with the software development team.  Rework, poor quality, crunched schedules, inadequate budgets, and poorly documented requirements are a shared responsibility of both the business customers (who need the software) AND the software developers.

Since the mid-1900’s, other industries such as manufacturing embraced evolutionary approaches to reducing rework, shortening development delivery cycles, cutting out waste and delays, and scoping out smaller bits of functionality to deliver incrementally, with transformational results.  Today a handful of the best practices have been adapted and tailored for use in software and systems development and offer similar transformational results to the IT industry.  Approaches like Kanban, LEAN, JIT (just-in-time), and others  make complete sense and increase team morale and the quality of the resultant software products, while reducing waste.

If you’ve never heard of Kanban, Outcome-Driven-Development, Lean Software and Systems Development, or a myriad of other named approaches, you might be out of touch – but you are also in luck, because there are resources available to get you quickly up to speed.

I’d like to mention a couple of notable resources here:

LSSC11-logo1. The Lean Software and Systems Consortium (LeanSSC) is hosting their second annual Lean Software and Systems conference (acronym LSSC11) to be held 3-6 May, 2011 in Long Beach, CA at the Hyatt Regency Hotel. Here’s a few important links that may be of interest:

2. Upcoming FREE webinars:

The Lean Software and Systems Consortium (LeanSSC)is hosting a series of FREE webinars commencing on January 18, 2011 to educate professionals who want to improve the productivity and quality of their IT delivery. Register today for one or all of these webinars.  Here’s the upcoming schedule of topics and dates for the webinar series:

If you are like me and catching up with all the Lean terminology…

I’m going to be posting frequently in the coming weeks and months about concepts, ideas, and general software development related to Lean, Kanban, Multi-modal approaches, and other topics – I hope that these will help you to catch up and help your company leapfrog ahead of your competition in software development.  And, I’d like your comments and feedback on what you think!

I’ll end this post with a couple of (what I consider) essential snippets:

  • Lean Software & Systems Consortium (LeanSSC) is a global, non-profit organization whose mission is to promote and create awareness of Lean Thinking applied to software and systems engineering and associated competencies.
  • From David J. Anderson on Yahoo discussion group kanbandev:  “I’ve jokingly referred to Kanban as “Outcome Driven Development” recently on Twitter. Some people thought I was joking 😉 as the ODD method hardly seems sensible! You are deciding the outcome you want (from a small change). You want code tested early to avoid it going stale. You want it tested while it is fresh in the minds of those who created it. You also want testing exposed as a bottleneck. You want the test bottleneck made visible/transparent/explicit. You seek to do this through a process (or system) change that introduces a WIP limit. Your hope (based on an understanding of theory, so it is a belief based on a scientific understanding) is that by setting a WIP limit you will expose the bottleneck and provoke further discussions that will change behavior, resulting in the outcome you desire. Your leverage point is the WIP limit. The WIP limit is the actuator you are using to stimulate emergent (desirable) behavior.”

Happy 2011 and I hope you’ll pass on this post to others who may be interested.  Join us on one of the Facebook, Plaxo, LinkedIn or other LSSC11 groups.  You’ll be glad you did!

Regards,
Carol Dekkers
Share

Jeopardy for IT projects... the answer is July 15

JeopardyIn the popular television game show Jeopardy, contestants are given short phrase answers and are challenged to pose the associated question.  The half-hour show has been a mainstay on prime time television for many years and boasts millions of viewers.

While Jeopardy provides great no-risk entertainment for contestants and viewers, a real-life “game” of Jeopardy plays out daily in corporations throughout the world, only it’s called something else: Date-driven-estimating!

Here’s how it typically plays out:
Business executive:  “July 15.”  (The Jeopardy style answer)
Contestant / CIO (pondering): “Is that the date you announced that the software would be ready?”
Business executive:  “Correct!  Now make it happen.”

Poor project estimating is one of the pervasive issues in software development – and the situation doesn’t seem to be getting any better despite process improvement models such as the Capability Maturity Model Integration (CMMI(R)) and formal project management.

It doesn’t seem to matter how advanced or mature is the IT organization – good project estimation is elusive.  When a project does come in according to schedule, it is often a matter of coercion – that is the project manager has cajoled, manipulated or somehow morphed the project schedule to match an often arbitrary end date.

Author Steve McConnell once coined the phrase “Date-Driven-Estimating” and stated that it was the most prevalent estimating method in use today.  In Date driven estimating, management announces the project delivery date and then the project team works backwards to the current date.  The worst-case (and not unlikely) result is when the project can make the date ONLY if it was started several months ago.  The schedule is then retrofitted by piling on more resources along the timeline until everything is included between the start and end dates.  Somehow, such artificial manipulation transforms the impossible schedule into one that can work…

In engineering projects where physical and scientific constraints are fixed (such as the days required for concrete to cure), it is easier to see that such practices are prone to create outright project failures before the project even gets started.  For example, a road construction project cannot be sped up by adding too many resources – physical limitations of engineering construction prevail and building codes govern project progress.  Not so in software development.  In fact, just this evening I met someone from a major financial services company who told me of a software project where the coding commenced within two weeks of the project start – even before they had documented the requirements.  (No, it was not an agile project!)

What can be done when there is a pre-set budget or firm schedule set before any requirements are documented?  From an investment point of view, customers want to curtail costs during the development and still get the software they need to improve their business.

From a supplier point of view, the goal is to get paid for the hours expended delivering the correct solution while being flexible to the inevitable changes that will happen along the way.

The two approaches seem at odds with one another – customers want to be fiscally responsible for curtailing costs, and suppliers want to be responsive to their customers yet get paid for the work they are directed to do.  Firm fixed price projects (even before requirements are known) have been the solution preferred by customers to minimize the risk of budget overruns but all the risk is assumed by the supplier – especially before requirements are known.  But as in any partnership there is no such thing as a win/lose partnership – if the customer wins and the supplier loses – both sides ultimately lose.

So, what can be done to avoid such a dilemma and achieve a win/win scenario?  One solution is to deliver bite sized, incremental 2-week software releases using Agile Methods (scrums) .  A two-week timeframe is easier to manage and gain an accurate estimate than is a long-term development project.

Another approach is unit pricing…. Unit pricing is based on working with a cost per function point (software sizing) and is a promising and realistic option to reach success.  This approach plus other evolutionary steps are contained in the northernSCOPE model – already successful in Finland, Australia, and other countries.

Watch this space for more about the northernSCOPE approach and upcoming US training workshops.

Meanwhile here’s a couple of earlier posts on the topics:

Isn’t it time we changed the channel and stopped playing IT Jeopardy?

Carol

Share

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
//

Defining IT Project Success

When the annual Standish Group Chaos report is published, IT professionals wait to hear whether the “project success rate” has gone up or down.  Between 1996 (the first year of the Chaos report) and 2006, the success rate doubled from a low of 17% in 1996 to a high of 34% in 2006.  Since then the rate has deviated up or down by a couple of percentage points.

In the Chaos reports, project success is determined to be on-time, on-budget, and delivering to requirements.  I don’t agree that this is a good assessment of project success, what about you?

[polldaddy poll=4093887]

Regards,
Carol


Share
//

"Scoping" out IT project failure...

According to a 2008 Gartner report, 15% of all IT projects failed that year because of high cost variance, while 18% were unsuccessful because they were substantially late. This means that in 2008, 1 in 3 technology projects failed.

Hmmm… IT project failure based on the fact that the estimates for budget and schedule proved to be incorrect.  Since many IT projects produce unique software products (i.e., never been done in exactly the same way before), is it any wonder that the estimates for scope AND budget AND schedule would be wrong?

Consider what this would mean in other industries if failure was based on having a high cost variance and substantially late (whatever “high” and “substantial” mean):

  • Medicine:  when a doctor “estimates” that a full term baby is due on Oct 15 and the baby is born on October 31 (16 days late) – is that baby a failure?
  • Medicine: when an oncologist “estimates” that a patient has 18 months to live and the patient is still alive 5 years later – is that patient a failure?
  • Survival: when the mining accident happened in Peru and scientists predicted that there would be casualties and all were rescued alive – was that a failure when the time frame exceeded the expectations and all miners were still saved?
  • Hurricanes:  when the scientist in Colorado predicts the number of hurricanes that will form in the Atlantic and how many will make landfall, and the number of storms falls short of his predictions – is that a failed hurricane season?
  • Everyday life: when you go grocery shopping with a list and a preset amount of cash, and you have to make several trips to purchase the items and they cost you more than you anticipated – is your Saturday a failure?
  • Everyday life: when your son makes the basketball team at school and your planned school budget is exceeded after shoes and uniforms – is the school year a failure?

All of these and many more examples in other industries illustrates how an “estimate” is simply a best guess based on history and science.  But life doesn’t follow science (truth can be stranger than fiction but that is another post for another time).  Just as a psychic cannot reliably predict the future (they can only make an educated guess based on intuition and observation), software estimators cannot reliably forecast the life of a project before it begins.  In fact, software estimators often work with even less predictable scopes than those outlined in the examples above.

So, in the context of a software project, what does on-time and on-budget really mean?  Given a set of approximate inputs for the major cost drivers (based on the information at hand) together with historical data for similar projects, an estimate is derived.  Will this estimate be correct?  Never!  It is always only a best guess given “typical” environment and situational characteristics – and an optimistic view of what could happen during the project.

If the estimator is gifted with a solid and complete set of requirements for a piece of software similar to a historical one, s/he might come within a range of accuracy.  Software, however, remains an amorphous product for which good requirements are often ill-defined or are discovered late in the development life-cycle.

IT project failure (in my humble opinion) should be defined based on scope – if the project misses the product requirements or gets them wrong, then the project should be deemed a failure.  Not whether it cost more than the estimator thought (which is a reflection on how good the estimator could predict life) or whether the product was delivered late (also a function of how well the estimate mirrored life).  It makes so much more sense to track project delivery based on scope!  But, wouldn’t that mean we’d have to concentrate on getting the requirements right and then delivering the product right?  That’s a novel thought.

What do you think?

Carol

Share