Author Note: This is a re-post of an article I originally wrote for Medium in January, 2018. Hope you enjoy! – Mark T.
I recently estimated a new software project for one of our clients. The system will be custom-built, and will handle some very unique requirements. As President and “Estimator in Chief”, this is a critical part of my job. I also pulled in our tech team for their opinions.
We asked ourselves the usual questions…
- Did we budget enough time?
- Who can do this work?
- What about competing priorities?
Yet we still needed to answer the most important question…Where are the pitfalls? If this thing can fail (which we all know it can), where will the failure occur? In other words, how much time should we allow to understand and plan for complexity?
Understanding complexity is a critical first step in any technology project. The good news is we have the right equipment to do it! The human mind has a tremendous ability to deal with complexity, and to expect the unexpected.
Our team identified the following questions to help deal with complexity. We recommend building time into each critical project task to contemplate these questions…
- Does this solve the problem?
- Should I be solving this problem?
- What happens downstream if I make this decision?
- What are the possible side-effects?
- Why? (and then ask “Why” again!)
As an example, let’s consider the design of a simple app to control the lights in my home. I first need to install hardware enabling each light for wireless connectivity. I will then build an app to identify each light by its location or function. Finally, the app will include an online toggle switch to turn the lights on and off.
But why stop there? I can add scheduling, alerts, personalization, failure detection, utilization monitoring, and much more. My simple app to control the lights is now becoming a major project!
Let’s say I’m a developer tasked with building the Scheduling Subsystem. I start by developing a calendar tool allowing me to update the On/Off status of each light throughout the day. Seems simple enough. But let’s go through the analysis to see where problems may occur:
- Does this solve the problem? Yes, the app enables me to schedule lighting changes in advance, and also on a recurring basis . This is a good start!
- Should I be solving this problem? Let’s say I also designed a timezone management function for my Scheduling Subsystem. This feature will convert “local time” to “lighting time”, simplifying user control from outside the target time zone. This seems like a great idea, but not necessary for Phase 1. Taking extra time to focus on the core problem helps to avoid unnecessary complexity. This is especially true early in the process.
- What happens downstream? Let’s assume there are two different developers. The first developer programs the On/Off Control. Unfortunately they don’t realize the importance of historical data. They store the data in an unstructured format not designed for reporting. The second developer arrives to build Utilization Monitoring. Their options are to work with the messy data, or re-program the data logging routine. A small amount of upfront planning would have made this much simpler!
- What are the possible side-effects? What if I allow multiple users to sign-on and control the lights in my home? It then becomes possible (and likely) that there will be conflicts. How should the team manage these conflicts? Will a conflict create a text message alert? Can we establish a user-priority to determine who gets control? If so, how many different levels of users do we need? The side-effects of adding multiple users must be carefully considered in advance.
- Why? (and Why again!): It’s important to challenge your decisions at each step in the project. For instance, If I decide to use a third-party tool for graphics design, why am I using this tool? Does it make my life easier, or does it introduce a significant learning curve? If that’s the case, do the benefits outweigh the risks? If not, you may want to avoid the new technology and consider a simpler approach.
You should always add time in your estimates to understand and plan for complexity. There are no hard and fast rules. The amount of time will depend various factors such as project size and percentage of new code. In our case, we decided to include one extra day per month (roughly 5% of the project) to asking these questions. We’ll let you know how it goes in future posts…Good luck, and keep it simple!