Case Study #1: 2014 Utility Company Upgrade (Part 2)
Posted by Charlie Recksieck
Good Decisions, AutoCAD and Otherwise
(Click here to read Part 1.)
* * *
Last week we attributed the high-level, macro reasons for why this project was so successful. Spoiler alert: Good awareness by the client and lots of adequate time for everybody to do their job.
Now I want to follow up with some of the more nitty-gritty details and the mini-successes within the project. I'm going to break this up into general software project items and then some things that are particular to AutoCAD (so you non-AutoCAD folks can skip, if you want).
Again, we'd love to mention this client by name, but they take customer information and that careful approach has spilled over to social media, etc. We respect that.
Agile Sprints vs. Large-Scale Traditional Planning
Agile Development folks have their own nomenclature and practices, it's a world unto itself (Google it if you don't believe me). We take Agile to mean working in smaller chunks within a project; the flexible nature lets us learn from our small "sprints" now that we are developing for real, then apply that to future sprints or goals.
More traditional "Waterfall" methodologies mean gathering requirements for the whole project up front, making deep master plans including software architecture decisions up front. We started this way in the late 90s when everybody was doing it. And I personally feel like this has been a little too discredited over the past 10 years. Case in point on this project: There were completely new APIs we needed to use that nobody had ever used, so we had to do proof of concept work on several of them up front to know if everything in our project was possible.
Also, on a multi-million-dollar project with lots of people and multiple companies involved, estimating budgets is not a casual thing. Management needed a price tag, so to come up with a reasonable estimate, the more requirements gathering and even architecture/design plans that can be made up front, then you'll end up with a good estimate and a plan for success. (Again, see Part 1 on this.)
In my experience, people in software have way too much emotional commitment to their work methodologies. "When you're a hammer, everything's a nail." Usually in life, the zealous commitment to one approach or another is usually inferior to a mix. We definitely did a mix here. We broke the project down to 16 areas, created a schedule for each, assigned teams. Each subproject had its series of sprints as well. At times, we were working on a few simultaneously, but rarely more than 3 at once.
Yes, we all live in a fairly virtual work environment. During these Covid times, even more so. When this project began in 2012, we at Plannedscape have been pretty virtual for a while. Each of us here worked from home already. We had a few clients we had never ever met in person. Some clients we performed our work directly on client machines or client networks through VPNs.
While remote work is great, on a biggie like this when it's time for lots of planning, sometimes you all need to be in the same room in front of a whiteboard. I put us all together onsite for 3 days at a quiet client office. Not only did this help our planning, but it let all of the client's team members meet and get to know our team members.
It's intangible exactly how much this helped the project, but I can tell you that it absolutely did contribute to the level of success we had. Robert, Brad and I still communicate with client team members, professionally and in off time, to this day.
Not only did we do that at project kickoff, but in key spots with more difficult subprojects and sprints coming up, we scheduled more onsite meetings, usually 2 of us there at a time.
Weekly All-Hands Project Meetings
Not an original idea. But instead of solely just small scrums, we had everybody involved meet on the phone conference for 20 minutes once a week. As long as those meetings don't drag, it's always a good idea.
Project Management Software
We didn't find any project management software that exactly fit how we wanted it for this project. With us being a software development company, we had the luxury of in-house skills to make a great, tailored web app for everybody to use.
This thing saved the project multiple times. Everybody always had their to-do list. Anybody in the project could see what anybody was working on. We saved "Open Topics" of issues to discuss and resolve. We tracked bugs and change requests. It documented the whole project beyond any reasonable expectations.
We can't advocate building vs. buying, that part was a little nuts on our part. But even before you schedule your kickoff meeting, get a PM product in place. And use it religiously!
Custom XML Configuration Files
On most heavily-customized software like what we did here, typically then the client is pretty beholden to the software designers to make any changes to the product. Even correcting a typo or changing a popup message's text requires a new build.
We have a good relationship with this client and we're not believers in developers having too much control over everything. Almost every things that's a message, setting or file name/location was put into custom XML files that sit next to the custom .DLLs we built for their apps.
So, if they want to start keeping a file in a new location, change a typo, or change what equipment gets ordered when designers click a single-phase transformer, it's completely under the client's control.
Time and time again, our external XML practices have let them change major things about the apps themselves; they can do it immediately and without having to pay us anything extra.
We even put a lot of the logic of decisions into XML; when the code has to make a decision, it can look at a custom XML value to see if "OrderGroundWire" is set to Yes or No, then it goes to an appropriate logic tree.
Companies Hiring Developers: If you're having programmers build something for you, see how much they can put under your control in easy-to-manage files.
Developers: You might feel that protecting these decisions in code is good job security and extra income for you, but avoid that temptation. Not only will you build better products and win customers over, but you'll also be happy to not have a long email chain instruction you to capitalize a word, then make a full rebuild/redeployment for a type.
Using Drawing Properties
Autodesk made a great innovation with their utility design product (AUD - "Autodesk Utility Design" at the time) to have all info about a work order or drawing actually travel with the drawing. In lots of software there are multiple files (like supporting XML or configuration files, external databases, etc.) that make up one "job". But their innovation was to have any settings like this embedded in the drawing. Yes, there are also internal databases in every AutoCAD drawing. But for this AUD software they decided that any text info about the job or drawing would get stored in Drawing Properties.
On this project, we fully embraced that philosophy. Any info we wanted to know about the drawing or job, we put additional info into drawing properties (aka DWGPROPS). As a result, anything we did with file management of drawings (moving to server, doing as-built production file transfers, etc.) was simplified by just moving the DWG.
We also developed a lot of code that would read or write to these values. A great repository of info at all times easily available to code. (We also wrote code that could read this info while drawings were closed; if you're curious about that, don't hesitate to reach out to us.)
Importing GIS Info
We leveraged AutoCAD Map native "MAPIMPORT" functionality to bring all kinds of basemap info into their design tool. But we also added a lot of innovative items in manipulating data that's brought in - checking for environmental requirements based on import, rotating street names, etc.
Integrating GIS and Design tools is an industry unto itself. But this was a foundational aspect of our design tool for the client. It allows designers to just window and area of basemap and then they are off and running; and finished design integrate easily back into updated GIS basemaps once new work is complete.
Make Good Internal AutoCAD Tools
You don't want to reinvent the wheel on AutoCAD code that you'll frequently need. It's incredibly handy to have canned, modular functions that you can call with a quick command.
AutoCAD examples in our project: Read/write drawing properties, read/write from internal database, read/write from external database, find/count blocks or features based on attribute values, insert borders in paper space, create views, etc.
That's just a short list of canned functions we made in our C# "Tools" project. If you use .NET to extend AutoCAD capabilities and are curious about some of these functions, again, go ahead and contact us.
I'm going to stop it right here before we completely go down a deep, deep AutoCAD rabbit hole and describe every little neat function we made in two years.
Hopefully, though, you learn something even generic in hearing particulars from case studies of real projects of ours. We plan to do more of these. As they say in songwriting, you can be universal by being specific.