We all know that change is hard. Sometimes people make it harder by resisting change rather than embracing it…even if the change is to their benefit! Try some of these tips for maximizing adoption and minimizing resistance when you roll out change in your organization:

• Demonstrate the benefits of the new tool to all affected & back it up with explanation of benefits to other staff for groups like IT that may not see direct benefit. The benefit to the company may sway some staff, but many will need to see benefit for themselves or their coworkers to buy-in.  Staff may benefit from the adoption of the new tool, for example, by becoming more valuable to the company—higher productivity, increased deliverables, and fewer errors all tie directly to higher revenue per employee & better customer satisfaction.  Staff that become experts  in the use of the new tool will drastically outperform those who are not—increasing the expert’s relative value within the company and thus their job security. By freeing staff from repetitive, low knowledge required tasks, staff will be able to increase their knowledge and skills in electrical design’s finer and more complex areas of knowledge.
• An internal ‘evangelist’ for the new tool, i.e. a positive and knowledgeable person, will go far in preventing other staff from becoming frustrated with new tools and giving up or turning negative. Some refer to such a person as a ‘change artist’. We recommend that your most positive minded, change embracing, and experienced designer be trained first in the use of the new tool.  If the person has the traits mentioned, they will highly likely naturally slip into the role of internal evangelist. If reasonably feasible, reward this person for being first, being positive, and for making the adoption of the new tool a success—the rewards need not be monetary.
• If involved from the very beginning in purchase and implementation planning, staff will be more amenable to the necessary process and standards changes that will affect how they work. Let staff know of the new tools on a timely basis, i.e. prepare them well in advance of the changeover so they don’t feel surprised or that their opinion on the changeover process was ignored. To increase buy-in, involve staff in planning the adoption process and in identifying what processes and standards will need to change.
• There will be staff that resist the adoption of the new tools, you likely have run into their resistance on any types of changes initiated over their time with the company. Have patience and help resistant staff see the value of the new tools to them personally. Their conversion will not happen quickly but over time they will accept the change and may even become some of the strongest proponents of the new tools.
• People learn best in different ways. Some learn best in a classroom situation, some learn best given time to experiment and dig around on their own. Budget time for staff to both take the training course and to have extra time on their first projects to allow for experiential learning, that way both types of learners will be accommodated. Ensure that all staff have unfettered access to either or both of expert internal assistance (from the evangelist mentioned above) and external assistance (from the tool supplier).
• Any change requires continuous reinforcement to keep the change process moving forward. Once you have told staff of why the change needs to be made and how it will benefit them and the company, tell them again…and again…and again…until adoption is complete, which will take months.

Change is never easy, but if you do everything you can to involve your people early and often, you will have an easier time rolling out the change.

ENSURING ADOPTION

Management makes a decision to use new tools either because external forces have forced the change on them or because the tool will benefit the company. People in general are resistant to change of any type, beneficial or not, so there is always convincing involved, sometimes coddling, and sometimes forcing!

The organizations that are able to most quickly adopt new tools and benefit from them are those that are able to create and maintain an environment that fosters quick and resistance free adoption. To do this, they will make it clear that staff success in the organization depends on their ability to adopt new tools as required. Organizations can also accelerate tool changeover by removing the old tools or only accepting delivery of product created with the new tools.

The executive(s) that make the purchase decision are the ‘sponsoring executives’. It is imperative that these executives stay attuned to the situation through the purchase phase, training phase, and adoption phase in order to lend support or gentle pressure as needed to keep the process of adoption flowing.

CONCLUSION

Failed adoptions of new tools typically happen because the executives that initiated or sponsored the purchase of the new tool think their job is done once the purchase is made. Natural resistance to change in the organization thus ‘kills’ the new tool in a slow and quite manner.

The reality of the situation is that the sponsoring executive needs to remain involved from the purchase decision all the way through to the completion of adoption by all affected staff. The time required of the sponsoring executive is not much, merely ongoing attention and encouragement toward the adoption of the new tools. In our experience, this particular requirement for facilitating adoption is the single most important task that needs to be done.

We hope that the information herein will help you and your organization in adopting beneficial new tools.   A successful adoption will pay off many times over in ongoing: productivity gains, accuracy gains, and increased employee satisfaction due to reduced repetitive work.

Regards,

Dean Whitford

Chief Operating Officer

DraftLogic

The accounting concept I am referring to is that of ‘Sunk Cost’. This is a way of looking at an expenditure that was made in the past that I think could help with a lot of present day decisions for many companies. You see, being human we tend to cloud what should be rational decisions with human emotion. Not a bad thing when a decision needs some emotion in it to make it smart, but a very bad thing when including the effects of emotion in a decision will result in a wrong choice.

Get to the point you say? OK, here it is: a sunk cost is money spent in the past. It’s gone, over, done, finito. The only value you should be concerned about is whatever real value remains today in whatever you spent the money on in the past. In many cases, the current value will have little to do with the money that was spent. All too often, we attach extra value due to emotional attachment. That incorrect adjusted current value prevents us from making smart decisions today.

At DraftLogic, we run into the effect of emotionally upcharged value quite often. We’ll show our revolutionary new product, DraftLogic Electrical, to prospects and they are invariably quite impressed. They talk things over at the office about upgrading to our software & all the baggage comes out of the storage rooms: ‘We spent years or tens of thousands or both on developing our CAD standards’, ‘We just spent hundreds of thousands on coding productivity tools’, or ‘We have hundreds of thousands invested in a software platform that would need to be replaced’.

The question that should really be asked is ‘Will this new investment pay for itself and start benefiting us materially within an acceptable timeline?’ If the answer is ‘yes’, the purchase should be made and the old investment salvaged/used if partial need continues, sold if it has no current value for the company but retains some value for others, or abandoned if having no current value for anyone. That, however, is assuming decision makers and users can remove emotion and politics from the decision making equation…and when is the last time you saw that actually happen? Back to our accounting analogy, even auditors whom are supposed to be the arbiters of dispassionate numbers end up accommodating for human emotion and politics in their work, thus some of the company failures that took us all by surprise instead of coming with much forewarning from auditors.

So to you I wish the gift of vision unencumbered by emotional baggage or politics! The best I have been able to attain so far is twenty-four hour clarity on decisions where I have an emotional investment–today I render my emotionally muddled opinion & sometimes I have to come back tomorrow and say ‘OK, you were right, that is a better way & we should go with it’.

Kindest regards,
Dean Whitford, COO
DraftLogic
www.draftlogic.com

The wrapping is in the recycle bin and the tree is back in storage…if you use an environmentally fake tree instead of something that gets burned after you use it for a few weeks.

How much use did the kids make of all the toys they received?  A couple of things still amaze me, even after my son’s fifth Christmas:  firstly, the generosity of his grandparents and aunties; and secondly, how little play time some of the toys get.  One can speculate that the toy designers are at fault & this is likely one of the factors.  In my son’s case, I think much of what happens or does not happen with the various toys is due to ‘too much choice’.

Too Many Toys

The fact of the matter is that he is spoiled rotten.  Hard to avoid when you are the only grandkid for four grandparents & thus also the only nephew for two aunties!  The gifts end up being either being used a fair amount over a long term, being used when mommy or daddy participate/mildly coerce, or simply not getting used.  When something comes in a really big box, the playtime with the box usually rivals that earned by the toy it came in.

Enough about kids and gifts and Christmas, otherwise I’ll start in on rampant consumerism being the downfall of western civilization!

How Does this Apply to Software?

Why did I bring up ‘too much choice’?  Well, the features of your application can end up in the same three ‘buckets’ as the toys: used a fair amount over a long term, only being used when trainers or support staff walk a user through it, or simply not getting used.  The worst of the second two classes of functions will not only not be used, they will get in the way and detract from your users’ quality of experience.  This is to say nothing of the extra time wasted in documenting, training, and supporting those types of features.

Featurus Overwhelmitis Causes

How does one get so many features in an application to cause Featurus Overwhelmitis?  For an experienced development team the reason is usually due to the higher the quality the development team, the more seemingly great ideas will be generated.  As project manager, it is difficult to withstand the constant onslaught of ‘great ideas’.  This is especially true if they are coming from your subject matter experts and you as project manager lack the domain specific knowledge to be able to separate the necessary from the beneficial but not necessary.  For an inexperienced development team, there is simply the feeling that users will see great value in an application if it has bazillions of functions.

The DraftLogic Electrical Experience

In building DraftLogic Electrical, we have tried to minimize Featurus Overwhelmitis.  On the intake side, feature requests and suggestions are carefully analyzed to determine how truly necessary they are.  Usually we can prevent low value add features from making it into the development schedule.  Where possible, we have completely integrated features into the workflow so that the user is not aware of having done anything extra, they just get the results they need.  Our fault levels calculations are a good example of this–they run anytime that the panel schedules, single line diagram, or bill of materials is run & ensure that those reports always have the most current data used in their creation (all load, protection, and feeder routines run for these reports–the user only has to call for the report).

On the development side, control is a bit harder.  Good developers will always have ideas about to do something better, take something farther, or offer another flavor of a feature.  The worst offenders (albeit well meaning) will go ahead and make extra features without clearance from the project manager.  Ever received three functions when you asked for one, accompanied by the comment ‘It was only a little extra time to do this that and the other thing so here are some great extras!’

The Repercussions of Giving In

I have to admit to occasionally succumbing to such deliveries and implementing the extra functions into DraftLogic Electrical’s menus and tool palette.  One such example are the three circuiting quality assurance routines.  Looking at them now, I wish I had sent the extra functions back and asked for the originally scoped single qa function that did it all.  I wish this so much that now I am going to have to allocate time for someone to consolidate them into one so I can get rid of the others and thus increase our usability.

Beating Featurus Overwhelmitis

So, project managers, stay strong and resist Featurus Overwhelmitis.  You can keep your development team and subject matter experts happy by adding ALL feature requests to a database or list.  When it is time to scope a new build, go through the list–when presented with cold hard choices of where to expend limited resources for development action items, a good development team will pick only the real gems for action.

Until next time for more software engineering ramblings,
Dean Whitford, B.Comm

Chief Operating Officer

DraftLogic

One day, Pog saw another caveperson, Grog, with a tool that had a shiny black head instead of dull grey like his.  Grog had discovered a deposit of obsidian and improved on Pog’s invention!  Pog found himself gathering wood in the same area as Grog and was amazed to see how much faster Grog was able to cut pieces of wood using his sharper and more durable tool.  Grog was happy to show any other cavepeople where the obsidian was, and many went with him to get their own pieces of obsidian.

Pog, however, had been using his dull grey stone tool for a long time and was comfortable with it.  He knew it took much longer to do everything, but the fear of trying to learn and use an new tool kept him from changing to the better obsidian blade.  Besides, Pog had invented the dull grey stone cutting tool, how could he abandon it!  In time, the obsidian users outperformed the dull grey stone users by such a margin that all the dull grey stone users died out and ended up merely as fossils buried in the soil.

How sad…if only Pog had not been afraid to adopt the newer, better tool!

THE DEVIL THAT WE KNOW

OK, you got me.  That was a rather long winded way of pointing out that we humans often stick with what we know and are comfortable with rather than trying new things–even if there is a strong probability that the new thing will make our work easier and/or better in some way.

We saw this happen twentyish years ago with the migration from manual drafting to CAD (computer aided design).  Thinking back in your career, you can probably remember situations where you saw people and/or organizations resist change that would have benefited them.

FLAVOR OF THE MONTH?

So should we go ahead and adopt every new tool that looks like it might benefit us in some way?  Of course not–you don’t want to be a member of the flavor of the month club, endlessly hopping from one half baked innovation to the next.

BEAT TOOL INERTIA

You still need to perform due diligence to ensure that a tool is truly going to benefit you.  Once you have performed due diligence, however, don’t let tool inertia bind you forever to the devil that you know!

Regards,
Dean Whitford, B.Comm.
Chief Operating Officer
DraftLogic
www.draftlogic.com

A LESSON FOR US FROM A REAL ESTATE AGENT

So am I writing today to pick on poor real estate agents and radio ad copy writers that accidentally pluralize ‘Internet’?  Nope, I am writing today because each time I hear the  advertisement it reminds me that not everybody on the planet is ‘in’ the information technology business.  This is important to remember for everyone involved in making or changing applications in any way:  project managers, software architects, developers, quality assurance staff, documentation writers, and technical support staff.

You can design and build the most fantastic application in terms of functionality and rock solid quality.  Without being usable by the intended audience, however, such an application is just as doomed to fail as one that is sparse in features and bug-ridden.

ENSURING USABILITY

How can you ensure usability?  First, it is important to understand that usability does have some core characteristics that apply across the vast majority of user audiences.  These are such things as following Windows conventions for the placement of menus, buttons, button names, button actions, etc.  In this regard, it is very important to NOT reinvent the wheel, i.e. stick with what is out there in common use.  Folks will thus have a head start on understanding how to run your application.

Second, usability beyond those core elements does change from user type to user type.  An application to help developers find memory leaks should thus have a user interface that differs materially from a bank teller application.

WHAT IS THE USER LOOKING FOR

So the core conventions are easy to determine and follow.  It is the special nuances that your particular set of users are expecting that are the difficult part to discover and implement.  You will need to determine who your users are going to be, what area of expertise they have, the terminology that is common among them all, and the lowest common denominator of information technology competence.

Each industry has its own ‘language’–terms not used anywhere else, or meanings for words that differ from how we use the same words outside the industry.  If your application is to appeal to these users and also to ease their learning of your application, you must be aware of these terminology needs and make use of them–or at least avoid any ‘faux pas’ by using words in wrong ways.

LOWEST COMMON DENOMINATOR

When you are looking to determine the lowest common denominator of information technology competence, you are not looking for the single most technologically challenged user in the group and then building the user interface to accommodate for them.  Your application would drive everyone else crazy in trying to be too simple to run!  Remove the outliers from consideration and look to where you find a strong cluster of users at the lowest level of information technology competence.  That’s your target of where to make your application usable with user interface design.

MULTIPLE WAYS TO RUN

Finally, if your user clusters are varied in industry and IT competence, you can always bundle different user interface packages to suit each cluster.  Investing the time to make your application as usable as possible to each different audience you wish to sell to will pay off well in increased sales, happier users, and reduced technical support needs.

Hey, do you think ‘See you on the Internets!’ has any change of dislodging ‘All your base are belong to us.’ from fame and fortune?

See you on the Internets,
Dean Whitford, B.Comm.
Chief Operating Officer
DraftLogic
www.draftlogic.com

SAY IT AIN’T SO, DEAN!

How did an ‘old development management sea dog’ like me get stung by not complying with these rules?  Well, truth be told, the reason lies with succumbing to two of the seven deadly sins!

Isn’t it funny how most of our human errors can be traced back to that simple list?

FEATURE GREED

My first sin this week was GREED–specifically, feature greed.  Talking only about development related sins, of course!  I wanted to show the potential client ‘the lastest and greatest’, ‘the best that we could be’, ‘the goodies’, you name it!  My rationale was that there had not been many changes to the application executables in the prior week, so after carefully testing the changed functions and passing them I thought I was good to go with the new stuff.

In the haze of feature greed, I forgot about our old friends ripple effect and fault feedback ratio.

TINY LITTLE WAVES MAKING BIG PROBLEMS

Ripple effect, for those not in the business, is when you change something ‘over here’ in your code and it breaks something ‘over there’ in your code.  It can be the fault of the developer not following through with a change to all affected areas or it can be the fault of the project manager not seeing all the modules that will be affected by a change and assigning all developers that own potentially affected code to do the necessary work to deal with the effects of the change.

In this particular case, I took a delivery from one developer that resolved some errors in one module, all of which tested good, then I took another delivery of fixes from another developer in a different module, all of which tested good.  It was the combining of the deliveries that was the problem–fixed functionality in the one module made code in the other module (changed weeks ago and tested OK at that time), blow up on finding data again where it was expected but in a now unexpected format.

NOBODY IS PERFECT

The essence of humanity, none of us is perfect, is demonstrated through the fault feedback ratio.  Nobody can go in and fix an issue without ever breaking anything else.  Developers that are very careful will have an extremely low fault feedback ratio, but even the best will break something else when they go in to make the fix.

This was the root of the issue that caused the error during the demo.  Code that at one time was synchronized with the output of the other module became unprepared for all possible variants of that output when a change was made in module A by developer Z.  This remained undiscovered for weeks because prior to Z making the change in A, developer X had broken module B so that it had no output whatsoever.  So only after the now broken module A was put together with the now fixed module B did the new error show up.

SUCK IT UP, PRINCESS

The net cost of my sins is the endangering of a sale that should have been a lot easier of a closing.

If you are not completely willing to bear the worst case possible outcome of a blown demonstration or production roll out, don’t release to production before something is completely ready and tested!  Given the vast cost of ‘broken arrow’ releases when you multiply by the number of users that you will take down for a while, premature production releases are simply not worth it.

FIGHT THE POWERS THAT BE

In my case, the decision was mine–no one was pressuring me for a premature release.

In many other cases, possibly yours, there is plenty of external pressure for you to release before you know you are really ready to.  You must resist, do not join the dark side!  For those that persist, quantify the worst case scenario in terms of user downtime and lost sales (or whatever set of effects would result) and the overeager stakeholder should relent from pressuring you…at least a little bit.

AN UGLY WORD UNLESS YOU ARE TALKING ABOUT THE SLOW TREE DWELLER

The second sin of the week was SLOTH.  In today’s parlance ‘laziness’.  I like to make it sound less bound-for-hellish by saying ‘lack of time’.  A proper amount of time allocated to make the proper tests would have exposed the issue and ensured that I stayed on the last release for the demonstration instead of the new stuff.

If one cannot make the time to get the proper tests done, one should not use the new release.  My failing was having a busy week with other matters and simply not having the time available, but in still doing the point tests and thinking that was enough.  It wasn’t, of course.  Complete system tests need to be done prior to releasing any code from development to production environments.

Licking my wounds,

Dean Whitford, B.Comm.

Chief Operating Officer

DraftLogic

Hockey is one of my favorite sports.  I love to play it, sometimes I like to watch it.  Even when you are playing, though, you watch while you are on the bench waiting for your shift.  It is when watching that one gains the most appreciation for the strategy and finer points of the game.  This is our first similarity to software engineering: the unbiased perspective, where you can really ’see’ what is going on, is only gained from being ‘off the ice’ or ‘not a part of the project’.  In either case, if you are in the action your perspective is tainted and you will make errors that you would definitely not if you were ‘off the ice’.  You’ll be a better hockey player, or member of an application development team, if you can lift your mind out of ‘the game’ to look at what is going on with some degree of detachment from time to time.

In the same light, I used to tell a sales manager that worked for me to ‘lift your head out of the swamp for a while each day’.  I said thus because he was getting so mired in the day-to-day goings on that he was losing sight of what we were needing to achieve in the coming weeks, months, and years.

TEAM COMPOSITION

Managing software engineering is my work.  The ‘game’ is application development, played out in offices and on computers instead of on a few centimeters of frozen water.  It takes a team to build an application, the larger and more complex the application, the more varied and specialized the roles on the team.  The need for a team composed of people fulfilling different roles is our next similarity.  In hockey, there are two wingers, a center, two defensemen, and a goalie on the ice at one time.  Each role requires a different mindset and skills to do it well.  In software engineering, we have project managers, software architects, developers, quality assurance staff, and documentation staff.

SOMEONE HAS TO BE THE BOSS

Each hockey team has one and only one captain, just as there must be one and only one head project manager for each application development project.  Someone has to be the boss, able to make the decisions that must be made in a timely manner.  Oh yes, there are assistant captains and vice-project managers, but the reality is that there needs to be a bit of benevolent dictatorship going on for a team of either kind to be effective.  Some of the toughest decisions involve whom is going to do what.  The average winger can’t play defense very well, and let’s not even talk about putting anyone but a born and bred goalie in-between the pipes!  In the same light, most quality assurance staff would not make good developers.  So, in both hockey and in application development, the ‘captain’ has to put each team member in the role that their skills and temperament make them most suitable to fulfill.  And those that don’t fit any of the roles needed on the team should be playing on a different team

THE DEVIL IS IN THE DETAILS

Finally, let’s talk about execution.  In hockey as in application development, ‘the devil is in the details’.  All the little things have to come together to make the big thing a success.  Passes that are crisp and on the tape, everyone giving their all from start to finish of the game, and playing your position properly.  These are the elements of winning on the ice.  Play the details right and the game will go your way.  The same goes for application development–good system architecture, robust and efficient code, effective quality assurance, and good usability make for a successful application development project.

OK, so MAYBE this whole blog entry is really kind of stretch…but at least I got to write about what I do and what I like to do!

Yours in software engineering,
Dean Whitford, B.Comm.
Chief Operating Officer
DraftLogic

“That doesn’t make any sense” you say?  Or perhaps you think the last percent of work should not be any different from any other part of the work?

Following that logic, our 20,000ish hour development effort should take a couple hundred hours for the last one percent to be finished.  The reality is we have burned five hundred or so hours and counting.  The light at the end of the tunnel is in sight but we are crawling toward it instead of running!

There are a number of reasons for that last percent of work taking such a disproportionate amount of effort to finish off.

HUMAN NATURE

A big part of it is the developer’s succumbing to human nature and the project manager letting such a thing happen…because it seems harmless when you consider the decisions one by one.  What I am referring to is most people’s tendency to go for the ‘easy kills’ when assigned a number of tasks.  We do that because we like the feeling of success and forward progress we get when we finish a task.  In organizations where there is performance evaluation based on completing tasks and having quality assurance sign off on them, going for the easy kills is sometimes an act of survival, i.e. the system makes you do it, regardless of whether you want to or not.

The project manager’s part of this is either not assigning a priority to the tasks to ensure that things get done in a particular order regardless of their relative difficulty OR in letting it slide when some of the developers skip the hard stuff.  My sin is usually the second type.

BACKWARDS RIPPLE

Another material contributor to the hours spent finishing the last percent of work is dealing with more ripple effects than usual.  Once your application is basically completely built, any change you make has a higher probability of affecting more code–much more in both respects than when you are first starting to build the application.

LATE STAGE REQUIREMENTS CHANGES

In the same light, requirements changes that are introduced at the end of the job have a higher probability of affecting more code.

DEALING WITH IT

So now we know how we got to this painful stage, how do we get through it?

This first thing is to manage the expectations of all the stakeholders.  Let them know that the task list is much shortened from before but that the items left are difficult and risky.  Let any of those who are asking for requirements changes know the full potential impact of their requested change & suggest, where feasible, that the change would be best left until after the first version of the product is tested and released.

The second thing is to maintain the development team’s morale.  Grinding through the tough tasks and dealing with ripple effects is going to be stressful, especially for those who either need or are used to frequent gratification from completing easier tasks.  Congratulate each developer for the small gains that will be made as they happen.  Keep the team updated about progress that is being made.

Finally, stay positive and stay focused!  Your clients on the one side and development team on the other will sense any fear or negativity you feel–and it will adversely affect their attitude.  Celebrate progress made, however glacial.  You need to keep your focus, the clients’ focus, and the development team’s focus all squarely on completing the product.  You will need to be strong in resisting any changes that are not absolutely necessary, whether proposed by the client or by your development team.  In this light, you need to be prepared to re-evaluate the inclusion of any functions that are causing major problems.  If feasible, delay a troublesome function for later in order to expedite the completion of the release.

NEXT PROJECT

OK, so you and your team pushed through the resistance and finished the release.  Can you avoid making the ‘last percent’ so painful on the next project?  Well, you won’t be able to get rid of all the nasty nuances tied to the last percent of work, but much of it can be managed away.

Ensure that your developer performance evaluation and task tracking system are sensitive to task difficulty and priority.  Do this by assigning higher completion credit to difficult issues & assigning an exact relative priority to each task.  The completion priorities must be enforced throughout the project, otherwise the tough items will pile up for late in the project.

Throughout the project, carefully evaluate any change requests, whether from clients or the development team, for the degree of ripple effect and for how truly immediate they need to be.  Change requests that can reasonably delayed to a future release should all be delayed.  Ones that cannot be delayed will need to have their time required, including dealing with ripple effect and added quality assurance time, push the project completion date forward commensurately.

Until next time for more software engineering ramblings,
Dean Whitford, B.Comm

Chief Operating Officer

DraftLogic