In my last two editorials, I documented a new conversion project that my team is working on. By the time you read this editorial, most of our features will be in the UAT (user acceptance testing) phase of the project, and if things go accordingly, we should be shipping sometime in the spring (fingers crossed). This has been a truly challenging project and I'm a bit floored that we've made as much progress as we have. By next issue, I should have a good idea if we can achieve the timeline I just mentioned. If we make the ultimate timeline of a spring deployment, I'll be even more astonished. Why the astonishment? Let's go back to the beginning…
Part 1: Act 1: Into the Great Unknown
Part 2: Act II
Part 4: Act 4: The Tenets of UAT
How It Started…
In mid-2017, my client began thinking about undertaking the wholesale re-write of the core applications used to support their business. During this process, we took a SWAG (Scientific Wild Ass Guess) at how long this project would take from start to finish. With an estimated spring start date, we coalesced around the idea that it would take approximately a year of development. So if things went well, we might, and I seriously mean might, meet that deadline. We are about nine months into the development process and (knock on wood) we might just achieve that goal. This project might just well be a unicorn (a project that comes close to the actual projected deadline). I don't know about you but delivering software anywhere near the original estimated ship date is a truly rare event, especially for a project of this scope and complexity.
The Plot Thickens
With a goal date in mind, we charted a journey into unknown territory. Although most of this project followed a fairly stock development process, there were a number of tasks that we knew would take serious creativity and innovation. With an already truncated deadline, we knew that these innovations might jeopardize the ultimate timeline. Projects of this size require some level of innovation and it's anybody's guess how long those innovations could take.
Eating the Elephant
Once our deadline was locked in, we tried to figure out what we could deliver using a phased timeline approach. In order to meet the deadline, we broke down the project into four distinct areas of focus: Business Unit 1, Business Unit 2, Data Maintenance, and Back-end Processes. The team thought that we'd be able to deliver code that could enter UAT for Business Unit 1 in the fall. After that, we could focus our time on Business Unit 2. The back-end processes and maintenance screens won't be counted as part of the deadline and could be delivered at a later date.
As mentioned in earlier editorials, the development process began with a small team of core developers. This team figured out the HOW of the project. How would code be organized, how would tests be written and organized, and most importantly, what we would need to build in the coming months. It was this last, the WHAT that was very important. In order to succeed in building Business Unit 1's application, we needed to know just what that was. Our first goal was to fill a backlog of work for our team to map out and scope the application. To help manage this process, we created a Kanban board and loaded it with all the screens, framework items, data conversions, and processes we would need to construct for Business Unit 1. Where possible, we included screen shots and the legacy functional design documents. This gave us a good idea of just how many tasks we needed to accomplish. This information was then given to our project manager. We started with one PM and now have three or four on our project. The project manager(s) created our burn down charts and other information that management needed to monitor our progress. If you haven't worked with project managers yet, you should consider it. We're lucky to have a great project management team because projects like this wouldn't be successful without them. So how did this planning work out? As of this writing, Business Unit 1 is well underway with its user acceptance testing. We now have 100% of our features in UAT.
So how is the work for Business Unit 2 progressing? We used the same process that helped build Business Unit 1's software. We built a backlog of work and immediately went to work building parts of our next module at a furious pace. By my estimation, we should be nearly code-complete by the end of January. This project has a much higher velocity than most as we've been able to leverage many of the components that we built for Business Unit 1.
The Question of UAT
Now the real question is: How long will it take our application to complete user acceptance testing? This is a big unknown and largely out our hands. This may be the most difficult timeline to gauge. Our code is thoroughly unit and integration tested and we have numerous gates that the code passes through before users get their hands on it. As Mike Tyson once said, “Everyone has a plan until they get punched.” As soon as users get their hands on your code, all bets are off. You never know what they'll find. I'll let you know how that's going in my next editorial.
