Category Archives: Technology conferences

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!

Carol Dekkers

ABZ's of Communication for PM's and Techies...R: it's all about Relationships and Rework

As we talk in the grander scheme of overall corporate communications, it all comes down to


Two different concepts but related as we’ll go into later.  Let’s start with RELATIONSHIPS.  If someone likes you and respects you, they will listen to what you have to say. If they don’t for whatever reason (that may or may not have anything to do with you!) – then getting them to listen to you will be an uphill battle.

Beca Lewis said:

“Yearn to understand first and to be understood second.”

This ties into a recent blog posting I discovered called “3 Deadly Sins of Business Relationships” by Diane Helbig.  The highlights of the post were that so many people go to networking events with an end goal in mind and in the process discard the importance of building the relationship first.  I know many of these goal-driven people (they are colleagues who brush past me on their way to the “kill” or prospects!) – they go to an event to get a preset number of qualified leads and work their way around the gathering like a fox on a hunt.  They are interesting to watch as they scope out their prey, approach the prospect, exchange their card, make their pitch and within 1.5 minutes move on to the next potential buyer in the room.  Often these “movers and shakers” end up leaving the meeting with what they consider to be a treasure cache of business cards – and think their time was well spent.

I’ve always approached networking functions with a different and likely less overall successful strategy – I simply like to meet new people.  People like me,  people who are different, people who have problems and opportunities and challenges and who are simply out to meet others.  At the end of the evening, it is as likely as not that I will have met a few new acquaintances and exchanged information.  Often it is simply a pleasant exchange whereby I’ve given them some information or a new idea that might further their business.  In the big karma bank of life, I might be truly naive in thinking that goodness given is repaid somewhere somehow when I need to make a withdrawal from the karma bank.  Certainly this is not a sales-focused approach, nor has it gained me any direct business ever!

I find the same situation arises when I attend or speak at major industry conferences. Perhaps I should have mined the lists of attendees, scoped out prospects and gone in for the leads, but that’s just never been my style.  Over the years, many colleagues have asked me why I bother to talk to people who won’t give me business – and my answer has always been that I genuinely like to meet like-minded people and that is satisfaction enough.  I believe that many of the contracts that I’ve gotten through word-of-mouth have come to me simply because I did not pursue people for their buying ability – and instead talk to them as people.

Read the 3 Deadly Sins of Building Business Relationships and let me know if you like it as much as I do!

Next posting – Rework and how much effort (and waste) it takes in communication.  Just this week alone, I’m quite certain that 1/3 of my time was spent on emailing people, following up when they didn’t answer, emailing yet again, calling and leaving voice mails and then still doing more.  What a total waste of time and energy chasing rainbows and promises that don’t deliver in the end!

Wishing you great relationships in all aspects of your life – and the communication success that comes from putting relationships before leads!


The "Dog Chasing its Tail" Syndrome in Project Estimating

Software estimating is plagued by dysfunction, not the least of which is estimation based on under-reported historical hours from previously completed projects.  See posting IT Performance Measurement… Time Bandits for a discussion about this problem.

BUT, other problems are prevalent when launching a project estimating initiative which I call the “Dog Chasing Its Tail” syndrome.  It symptomizes dysfunctional project behavior that is established and continues to be reinforced to the detriment of the organization. As a result the pattern repeats and process improvement is seldom realized.

What is the Dog Chasing its Tail Syndrome? It’s a noble goal to increase the predictability and reliability of project estimates – when estimating is based on sound principles.  However, estimating is often a misnomer for what should be called “guesstimating” because the data on which estimates are based is sketchy at best.

Here’s the process epitomized in the “Dog Chasing its Tail”:

1. Incomplete (or preliminary) requirements and sketchy quality/performance requirements. While preliminary (no formal requirements or  use cases are known), it is customary for management (customer or supplier or both) to demand a project estimate for budget or planning purposes. Labelled initially as a “ball park estimate” (a rough order of magnitude (ROM) guess of whether the effort is going to be bigger than a breadbox or smaller than a football field), the sketchy requirements are used as the basis to get the ROM.

2. The (Guess)timate becomes the project budget and plan. While management initially understands that an estimate is impossible without knowledge of what is to be done, estimators contribute to the reliance on the guesses by providing them with a feigned level of accuracy (e.g., if requirements span a total of two sentences, the resultant estimate may include hours or dollar figures with the ones digit filled in.  As a result, too often the (guess)timate becomes the approved upper limit budget or effort allowance.  Of course these figures will be proven wrong once the solid requirements are documented and known, but we are now stuck with this project estimate.

3. Changes challenge the status quo budget and schedule. When a change or clarification to requirements emerges (as they always do when human beings are involved), there is often a period of blame where suppliers allege that the item in question is a change (addition) to the original requirements on which the estimate was based, while the customer alleges that it is simply clarifies existing requirements.  Of course, neither one can be proven correct because the requirements on which the estimate was based were sketchy, incomplete and poorly documented. Once the dust settles and it becomes clear that the item will impact the project budget and schedule, the change/clarification is deferred to the next phase (“thrown over the fence” as an enhancement to be done in the next release) where it will be poorly documented but we will estimate it anyways, and so the cycle continues.

Dog chasing its tailIf you’ve ever had a dog – you know that this is similar to a dog-chasing-its-tail whereby the behavior goes on until either the dog gets tired or gets distracted by other things going on (such as food being served).  As smart software engineers we ought to be smarter than dogs!  And, given a scope management approach, we can be!  Break the cycle off dysfunctional estimation and investigate scope management – you and your customers will be glad to move forward rather than facing the insanity of repeating the same process over and over and expecting different results (along the lines of the Einstein quote!)  See for information on scope management training and resources available to break the “Dog Chasing its Tail” syndrome on your projects

Watch for the upcoming post on the hidden dangers in project hours…

To your successful projects!


Carol Dekkers

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her ( for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest solutions that work in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

IT Performance Measurement - Don't let time bandits prevail...

Here in FL, Sunday is one of my favorite days to sit outside on the deck overlooking the mangroves (yes, spring break weather is FINALLY here!) – and read the bulging Sunday newspaper.  I am always intrigued by the many topics in Sunday’s edition, and there’s always generalist stories that remind me of something that happens with software.  This week was no exception.

I’ve nevTime Banditser seen the syndicated column called “The Ethicist” by Randy Cohen (syndicated from the NY Times Magazine), but today’s column headline:  “Underreporting hours worked puts unrealistic goals on others” caught my eye… just the title reminded me of one of the biggest problems with IT measurement:  project hours in IT are typically under reported because of unrealistic project budgets, overtime rules, accounting practices, etc.  (In my experience with measurement and productivity work – this is part of what I call the “Dog Chasing Its Tail” syndrome but more about that in another post.)

Back to the Matter at hand… In this week’s column, (originally published in NY on March 11, 2010, and in my St. Petersburg Times March 14, 2010), Randy Cohen is presented with an ethical question:
“As a manager at a large company, I work far more than the required 40 hours a week, but report only 40. If I reported my actual hours I could be penalized financially for letting my projects run over budget.  Company policy states… <snip> … is there a problem with simply declining to mention some hours when I did work?”

The crux of Randy’s answer (as it related specifically to IT Performance Measurement for me) was “By underreporting your hours, you create a false sense of your efficiency.  The company now believes that you are able to complete your weekly tasks in 40 hours. But you are not. Your deception thwarts the company’s reasonable interest in assessing your performance”.  To use a Canadian expression Bang On with your response Randy! (to read the entire article by Randy Cohen, click here.)

This is one of the most pervasive problems when tackling software project estimation – using reported project hours as the basis for new project estimates (when the actual hours are much higher). Most people would see the folly of estimating the cost of a new based on the mortgage of a house down the street (you don’t know how much was the down payment!), but overlook the hazards of doing the same thing when estimating a software project based on under reported hours.  Both fall victim to the wrong foundation for estimating.

Before you embark on a process improvement initiative that targets Predictability and IT project Estimating, make sure that you know all the facts before you waste valuable time or energy compounding the existing problems and ignoring the real status quo.  Become knowledgeable about the issues (call or email me if you need a starting point or resources.)

To your successful projects!


Carol Dekkers

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her ( for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Crosstalk article on Scope Management

CrossTalk - The Journal of Defense Software Engineering

CrossTalk Jan/Feb 2010 Scope Management: 12 Steps for ICT Program Recovery

by Carol Dekkers, Quality Plus Technologies, Inc.
Pekka Forselius, 4SUM Partners, Inc.

The information and communications technology (ICT) world is “addicted” to dysfunctional behavior and the problem is spreading globally. The sad truth is that the parties in the ICT relationship (the customer and the supplier) are largely co-dependent on a pattern of dysfunction characterized by ineffective communication, fixed price contracts with changing requirements, and eroding trust. This article focuses specifically on the northernSCOPE TM 12-step process for ICT program recovery.

For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit

To your successful projects!


Carol Dekkers
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

Measuring IT Performance

Quote for those tasked with implementing a sustainable measurement program with positive ROI:

“When we seek generalities we fail.
When we seek specifics it is easier.
When we measure performance, performance increases (Hawthorn effect).
When we measure and record performance, performance accelerates.”

Source: Anonymous.

Where Should one Start when Tackling a Software Measurement Program?

Overheard at a recent IT software conference:

  • “Okay, so I guess the 1st step is to measure function points” (Dekkers’ comment: Sorry, wrong approach. The 1st step is to figure out the Goals that you want to achieve with measurement.  Think of this like going shopping – what do you need to buy – you only make a grocery list of what you need once you know what you want to cook. The same thing goes with software measurement! Deciding your goal (s) is the first step)
  • “It sounds like I need a measurement consultant but how do I choose one and what will it cost?” (Dekkers’ comment: There are more than enough eager software measurement consultants who will tell you their way is the best and only way.  One group touts themselves as the elders of software measurement and holds up their volunteer committee service as their mantra, while many of their consultants are hired guns – that is they are subcontractors who work freelance for the highest bidder.  Make sure to ask for (and check) references and ask those references what their ROI on the consulting group was BEFORE you take the salesman’s word for it!  Buyer beware – there’s some unscrupulous fat cats in the water who will take your money, implement useless difficult measures, and be gone leaving you holding a dashboard that doesn’t match what you wanted to achieve.)
  • “Software metrics sounds easy but the presenters make it sound hard” (Dekkers’ comment:  Software metrics is NOT rocket science or even difficult. Follow Goal-Question-Metrics (GQM) approach, engage a bit of targeted training, and take it one step at a time and you’ll see that you too can be savvy with software metrics and gain performance improvement.  Take a look at the FREE materials on Practical Software and Systems Measurement (PSM) from and from CrossTalk ( – search for software measurement and from the DACS ( which are all US taxpayer funded initiatives for a starting point).

Make sure you take advantage of the many free article downloads at or send me a note at before you hire a consultant to design a function point or software measurement program you’ll later regret.

To your successful projects!


For more information on northernSCOPE(TM) visit (in English pages) and for upcoming training in Florida, visit
Carol Dekkers
Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, with straightforward and honest expertise that works in the real world!
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

ISO/IEC JTC1 SC7 = ISO Software Engineering Standards

Hello from Hyderabad, India, where I’ve attended the ISO/IEC JTC1 SC7 meetings this week – sponsored by NASSCOM of India.

It is refreshing in this year of global economic downturn to see that countries are continuing to think long-term with regard to ISO standards and their evolution.  Here in Hyderabad, NASSCOM officials and TATA consulting executives ensured that our stay was incredibly safe, comfortable, and highly supportive of the intensive work done by SC7 working groups writing the world’s emerging software engineering standards.

In addition to the professional support offered by the attending 60+ Indian professionals attending the meetings on behalf of the Indian national standards organization, the arrangements provided for luxury western-style accommodations and meals, and lavish outpouring of India hospitality. Despite this being my third trip to India (the first two featured Delhi and Bangalore locales), it has definitely been my best and most memorable.

On the standards topic, there are many emerging new work items concerning pressing concerns in the global software and systems industry including IT service management (ITIL), corporate governance, documentation standards (worldwide), benchmarking, software and systems processes, etc.  If you’d like to know more about the standards that may affect YOUR company, contact me at the email address below and I’d be happy to answer them.

Sometimes ISO standards (and ISO/IEC standards) get a bad rap in the industry press as being out-of-date, clumsy, difficult to implement, and theoretical in nature.  As a 15 year representative on behalf of the USA to ISO, I can only say that things are on the mend.  More and more liaisons, fast tracks, and adherence to timelines are imposed – making our writing job a bit more rigorous and fixed, but at the same time, delivering standards to the market in a more streamlined manner.

For further information on the ISO/IEC standards processes or standards themselves, please send me an email.

Have a great week!


Carol Dekkers

Contact Carol to keynote your upcoming event – her style translates technical matters into digestible soundbites, humorously and forthright. View also Carol Dekkers’ general blog at The Dekkers Report
=======Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED =======

The Future of Technology Conferences...

Depending on your age, you may or may not remember when… technology-centric conferences were in their infancy in the late 1970’s. It was a time of abundance and technology was new and exciting – and colleagues would sometimes select the conference for the half-year (two to four conferences a year was the norm) – based on the exotic locale?
Without reference to age, some of us even may remember when… conferences grew larger by the hundreds every year based on positive word of mouth and the location?
Remember when… budget and training dollars were granted when you applied to go to a particular conference, and then additional dollars were authorized when you found another equally “not to be missed” conference after you got back from the first?

Those were the boomtown eighties all right! Ok, I’m old enough to recall attending international specialty workshops, training seminars, and software development conferences with hardly more justification than the conference brochure – and we certainly didn’t need to submit triplicate copies for every lunch and coffee receipts for every day of every trip. Today, things are vastly different and the whole traditional, in-person conference is a big make it or break it expenditure for the corporations and not-for-profit groups alike. And, with the downward trend in attendance, it can take a single poorly attended conference to wipe-out an organization’s assets. What are the challenges that technical conferences are up against these days? Here’s a few of the emerging trends:

1. Increased competition for conference dollars

It is virtually impossible to keep up with the explosion of specialty “international” conferences that pop up almost weekly. It appears that anyone who sees that a buck can be made if you can just “tap the right market at the right time” seems to have gone into the conference business. ABCD (or some other clever 4 letter acronym) springs up and touts itself as “the provider of the premiere conference experience”. Or it is common to read “Ixxxx Institute presents the first ever blahblahblah conference” as a conference headline. Be careful how you allocate your conference dollars before you trust the printed brochure to make sure that value will be delivered. It is good practice (but not a common practice) to call the organizers ahead of time and ask for the names of five of last year’s attendees, then follow-up with them by phone or email to ask what they thought of their conference experience. Be wary if all of the attendees are board members or a member of the conference planning team. Otherwise, if the advice is “skip this one” – you know that you’ve probably saved your company travel money, conference fees, and workshop fees – and have crossed one tenuous conference off the list.

2. Conferences that sound too good to be true probably are.

Watch for fly-by-nights in today’s money hungry economy, there are those who think that any popular topic will pack a conference – and that is partially true. Agile, SOA, Open source and Web2.0 conferences are popular and currently still amassing good turnouts. When we’re talking about the amount of money generated at a well-attended conference (1000 attendees at $1000 per attendee is big bucks!), there are those who may get greedy and put customer satisfaction and value and speaker treatment on the bottom of their list of priorities. Make sure that all of the speakers listed for the conference will be appearing live and in person if you want to meet the speaker as there are conferences today that “beam in” a satellite feed of the speaker at another venue (like on the academy awards with entertainers who couldn’t make the live show!) or sometimes even run a pre-recording of the speaker delivering his/her presentation. Especially watch this at conferences where the speaker lineup appears just too plentiful and illustrious to be true – because it probably is!

3. Webinars and podcasts are the rage today

Remote, small bite sized presentations on a particular (usually highly focused) topic packaged as a low-cost or free webinar seem to increase weekly. While webinars were once limited to high-technology companies seeking to demonstrate their software remotely, the webinar and podcast (usually audio only as opposed to video for webinars) frequency have taken over the mainstream of technology offering topics ranging from coding tips to software development methodology. Why go to a conference if a webinar will deliver the information directly to your desktop?

4. Open universities

Did you know that anyone with an internet connection worldwide can attend classes remotely at MIT and other major universities throughout the world? While a degree is granted only to those paying students, others can watch and learn for no cost by simply accessing the university site and selecting the topic and date for the class and “tuning in” (double clicking on the selected video link). For example, Thomas Friedman’s lecture on his book The World is Flat from May 2005 at MIT can be readily viewed at anytime day or night. Visit MIT open university at

What’s the future for technology conferences? If there’s the right combination of location, people, topics, and proven good speakers delivering content rich presentations, then there will always be a market for well attended in-person conferences. However, miss one of the ingredients or have a stale or old school style conference where the same old presenters present the same old stuff at a conference run by the same old not-for-profit board members, and you’re going to see a decline in attendance no matter where you locate the conference.

It’s going to be interesting to see which conferences survive and thrive in 2009, and what conferences simply disappear from the landscape… any guesses from your vantage point?

Have a nice week!

Carol Dekkers
———–COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED————————