Plannedscape Postings

  • Blog Home
  • /
  • Case Study #1: 2014 Utility Company Upgrade
Image

Case Study #1: 2014 Utility Company Upgrade
Spoiler Alert: Taking Time = Success

Posted by Charlie Recksieck on 2020-07-30
From time to time we want to present case studies showing what worked (or didn't) on past projects. While it might act somewhat as a window to our practices and philosophies here at Plannedscape, more so we hope that you see something that resonates with your projects and helps them succeed.

* * *

We're so proud of the work we've done for this ongoing client. We'd love to mention them by name but we're aware they take privacy seriously when it comes to customer information and that careful approach has spilled over to social media, etc. A couple of times we've removed fairly innocuous, complimentary Twitter shout-outs and taken them down at their request. Again, tip of the hat for your dedication to privacy.


The Project Goals

Anyway, the project here had to do with this electric company's design process. To fulfill requests for new power, they used Autodesk (at the time) software that runs on top of Autocad to allow designers to import base maps (and GIS info) to a new design, drag and drop new electric items (like poles, lines and transformers) and use intelligence to get lists of material to order, make estimates and eventually put material data in their work order management system, and prints the work order maps for the construction crews, among other things.

We here at Plannedscape had been helping them add on a LOT of custom features over the years; we began working with them back in 2002. The customization of material ordering forms for their electric designers really were groundbreaking in the industry.

Starting with discussions in 2011, the underlying software ("Autodesk Utility Design") was going through massive changes. Previous configuration and code (for all AUD customers, not just this client) was going away and companies with previous customization would kind of have to start over when it comes to configuration and customization of the product.

The assignment here was to rewrite all of their customization/code in a way that interacted with new version of AUD, utilize brand new and undocumented product APIs and preserve each and every feature they and we had developed for designers at the company.

Companywide their estimate accuracy and ability to on-board new designers quickly was truly an industry leader. Long story short, they had spent years developing cutting-edge tools and they didn't want to lose them due to a mandatory upgrade to the new version of the primary software.


Bidding The Job

There were only two realistic companies that could have conceivably bid this job: 1) Autodesk Consulting, which had a leg up since Autodesk was the developer of the primary software they needed to upgrade to, and 2) Us, Plannedscape, who'd developed most of this company's design tools and two of us here had previously worked for Autodesk and the previous company that originally developed the software.

Autodesk Consulting should have had a huge advantage over us. They had dozens of developers in-house whereas we had a max of 3 people available for the project. Autodesk Consulting, in theory, could have thought of a low price on this customization work as a "loss leader" for getting a marquee company to do a landmark, highly visible upgrade to their new software. It would have been a valuable political "win" of a project for Autodesk’s reimagined product and Autodesk Consulting would have had a tentpole client to show off.

Let me say this about the project: There was a LOT of complexity to it. We eventually broke it down to 20 mini-projects, each involved with a discrete feature in their design system (importing maps, Autocad frame placement, ordering electric lines, transferring as-built drawings, e.g.). And lots was to be done using new Autodesk APIs to interact with the software; these APIs had never been used outside of core code.


How David Won The Bid Instead Of Goliath

Without going into the weeds of the actual content of the bid, our Plannedcape bid was actually significantly higher than the larger Autodesk Consulting's bid.

But the other key way in which our estimate was larger was the size of the document itself. Ours was 65 pages long, with extensive breakdown and preliminary software architecture ideas for each of 20 project areas, assignments of team members from us and the client, and cascading schedule of sprints to be accomplished over 24 months.

Our competition, Autodesk Consulting, put together a 5-page proposal with no breakdown of project areas, understanding of current functions. Of the 5 pages, 3 were more contractual in nature than discussing software plans.

The client went with us. (Spoiler alert.) From what I heard, it ended up being a surprisingly easy decision for them to make; upon seeing the level of detail in our proposal, the fact that Autodesk Consulting asked no requirements questions for the bid, etc. - it was, basically, just a number without actually listing the scope of deliverables. This should be scary to any company receiving a bid. I’ve said this before "A goal without a plan is just a wish" but here’s a corollary: An estimate without listed deliverables is not an estimate.


The Real Reason We Were Chosen (And Why They Succeeded)

In the previous section I'm unsubtly implying that it's our talent and attention to detail that shone in the end. But the real key is that they were a knowledgeable client and smart, dedicated people up and down the chain of command.

Too many companies have price as their main criterion for selecting a contractor (software or otherwise). Not only was this client able to see that our proposal was a true plan to carry us all through the full two years of the project, but they were alarmed by the lack of detail in the other proposal. These were experienced professionals and could see that had they gone down the wrong road, any money savings "going cheap" ultimately would be blown away by massive schedule overruns, change requests and eventual cost of 2x-3x what we bid from Plannedscape.

(Full disclosure: Another reason that our small firm got the contract and not Autodesk Consulting: Their legal team insisted that they owned the code developed for the project that they were charging full price for. They SHOULD have gotten this job, but we did. I 50% believe we got it just because their lawyers got in the way.)


Client Dedicated To Success

It's killing me to not give these folks a shout-out since we've respected their decision-making for so long. But oh well.

I had spec'ed this project out to take 24 months with our Plannedscape full-time resource allotment of 2.2 developers for one year and 1.5 developers for the second year. They didn't engage in wishful thinking and insist on 18 months instead of 24. They didn't kick any of the 20 features/subprojects down the road to cut corners.

We always got answers and files from them whenever we needed them. And promptly. Basically, management and all team members bought into the project and were invested in success.


Time

I can’t underscore enough that the time alloted was a key. Too many nervous project managers want to see code being written by the third week of a project. Nobody every took that attitude here.

We were writing in a brand new environment: C# where previous code was in VBA for AutoCAD and LiSP; there were lots of overlaps of different commands/processes needing to use more generic common code functions; lots of code needed to communicate directly with the core software’s APIs which were completely undocumented and many were never actually used before (even by core product code).

The first two months of the project were just exploratory proofs of concept, writing of generic functions to use (like text handling, file management, creating business objects) and meetings where decisions where actually made. This was the foundation of the whole project. Every sprint after this went fairly smoothly. I don’t remember any degree of panic on any part of this massive undertaking, which I attribute to a really sensible first couple of months. I hate to say this, but that experience is the outlier and not the norm in software development in real-world practice.


Sometimes It's That Simple

I could go to great lengths here to explain small low-level details of little things we did right, nice innovations we made, smart suggestions from client employees, etc. Believe me, all of that little stuff was important. (And we’ll cover that in a Part 2 aimed at Autodesk readers and users.)

But they were only possible because we were given ample time (and smart project deadlines). That meant everything. Instead of being pushed to cut corners, we never had to consider that. Everything we did for the first four months of the project could be seen as "measure twice, cut once" kind of stuff. (This is a simplified version of what went right; there were lots of great micro-decisions about specific functions, Autocad, etc. that we’ll cover in that Part 2.)

The broad lessons of this case study aren't very mysterious. Everything worked because everyone on the client side wanted this to work, and management signed off on a very reasonable schedule. It's not a coincidence that project was internally seen as a great success.


The Takeaway (Part 1)

When it comes to competing bids, cheaper is not always better.

More importantly, do your due diligence, do the research. If that leads to an estimate that calls for 24 months of work, then make the project 24 months. (Better yet, make it 27 months.) Basically, our client didn't engage in wishful thinking - which is huge! Things worked out.

FYI, we still work regularly with this client every month. They keep innovating with their design tool, further extending what we did on this project in 2012-2014. It makes us proud to work with them. In fact, I need to stop writing this right now to get to a phone conference with them.


Coming In Part 2

The more granular version of Autocad-specific things that made this project a success.