MEETING BUILDERS WHERE THEY ARE:

On a related note to my last post... one of the tenets we followed when building our production builder application "Dynami Builder" (http://www.dynamisolutions.com/) was 'meet the builder where they are' - we knew that anything more complicated than "minimally disruptive" could not/would not be deployed quickly at the client... and not getting it up and running quickly (6 months or less) means stretching out the ROI unacceptably... maybe to 'never'.

THE 80-20 RULE
Return On Investment stretching to "never" means "No Return - No Value". Thanks to research analysts like Forrester and Gartner Group, we now know that (in other industries at least) 8 out of 10 of ERP and CRM (big software) implementations FAIL. 80% failure rate overall, and I'm willing to bet our industry is that bad, or even worse. Think about the big "integrated" builder software systems... I've seen hundreds of builders attempt to stand them up, but can only count the ones who wind up using them as-intended on one hand.

Talk to the employees at even the most tech-savvy builders out there - Like Capital Pacific or John Weiland Homes - the ones who are written up over and over in the trade publications... and you will discover that their use of technology is nowhere near as robust as it is portrayed in the press. Sure, they use "BuilderXYZ"... but it turns out that they don't really release POs from it. Or, they use "SalesAutomationEasy" but are still printing out paper selection sheets. Or "WarrantyListMaker" but are having to re-key months of job information.

Small-Volume builders are no better. Take Synapse Software's "BuildWorks" as an example... even though BW will provide a nearly out-of-the-box mechanism for a builder to get accurate purchasing and job-costing out of QuickBooks... it requires some set-up in Excel. So you will find the typical user loading the accounting file only, and not using any of the Excel features that power the job-costing - even though they are relatively "free". And once they're set up, they could be saving a small builder thousands of dollars.

A MAJOR REASON SOFTWARE PROJECTS FAIL: STAFF TURNOVER
So several years ago now I started to research why those projects were failing at homebuilders, and I found the usual littany of reasons IT projects fail at any business... all relating to failure to follow the top-down protocol:

- Wrong vision by Sr. management (the Wrong Why)...
- Right vision but wrong objectives (the Wrong What)...
- Right leadership but wrong product selection (the Wrong How)...
- Right product choice, but no action plan (the Wrong Who/Where/When).

But one reason had nothing to do with intention or planning, and stuck out like a sore thumb - production builder staff turnover is typically very high, even at the management position level. It was not uncommon for me to start a project with one set of people, and after a year, nobody was left but the company owner.

Think about that.

So these weren't really "management teams" enabled to steer the ship on a common course. They were loose collections of people assigned titles by the company owner, but not given any framework to operate in, no metrics or benchmarks to manage their departments against, not given any recognition when things went well, but hammered mercilessly when they didn't.

Our IT project would often be the last straw... one more hassle they couldn't take, so they'd find new jobs at other builders (often with no notice or fanfare - they'd just split)... who weren't any better at management, and the cycle would repeat.

CALL US WHEN YOU'RE DONE...
So the software vendor (any vendor) comes in... evaluates the situation... gets a plan together (hopefully - not always)... and starts the implementation of their product or service. But their fatal mistake - they allow the builder's management team (remember, the team that really isn't a team...) to drive the velocity and urgency of the implementation, often because they're juggling way to many clients themselves to do it any other way. "When you're done with "A", call us and we'll come back and start "B"

Therein lies the problem:
By the time "A" is done, the staff member who did the data entry moves on to another job in another town... and "B" can't start because nobody knows where "A" was left off. So we're

I can not think of an IT project that lasted a year where I had all the same players as when I started.... but worse, I've personally been involved with a more than a dozen of these projects where the ONLY person remaining from the original management team... was the owner of the company!

And since he/she didn't make the project a personal priority in the beginning (abdicating responsibility to someone else instead), he/she was also in the dark, and by this time clueless, very PO-ed at the software vendor, and probably his/her consultant as well.

At that point - it's too late. At Dynami, we consider disengagement of the company owner to be a "Terminating Factor" -meaning 'game over' - suspend the implementation.

In my experience, anything else that gets accomplished after that happens, will occur in an environment of infinite mistrust and CYA, and winds up producing a fraction of the value it could have had everyone stayed on board.

Think of what one of your housing projects would be like if you took the "Call us When You're Done" approach with subs.

"Ok Tom... let me know when you're done with the drywall....then we'll start calling around for painters.... "

That's why, we decided to take a very pro-active approach to implementation. It's 16 weeks, period, because we drive it to be 16 weeks. We help the management team gell through regular accountability meetings, and we provide the builder with cutting-edge tools they can use to apply top-down thinking to any project. Even if a builder is considering other projects, software, whatever... if they do our "Blueprint" first, they will be in a much better place to tackle whatever they want later. Moving the management team forward together is the key to a successful software implementation project. If the builder has people on the team who shouldn't be there, or if the owner isn't ready to delegate and then step back and manage... the project has little chance of success.