Your project is doomed to be late and over-budget if you don’t manage it
The new year is well underway and software dev teams everywhere are kicking off new projects. Optimism is in full swing, perhaps because of the longer days, more sunlight & the steady decline of COVID cases but more likely because humans are fundamentally optimistic, often to a fault. Now is the time to take the precautions needed to get your project off to the right start and ensure successful completion. There are a variety of considerations to size up your project and several key steps to kicking things off. Planning is critical - not that your plan has to be set in stone, the plan itself can change. The important thing about planning is the process of planning, not the plan.
“Plans are worthless, but planning is essential.” — Dwight Eisenhower
General Eisenhower’s famous quote “Plans are worthless, but planning is essential” speaks to the value of planning and what it produces beyond the plan itself: Assumptions, Constraints, Contingencies, etc…
The act of planning allows the team to explore the territory and boundaries of the project, gaining important knowledge that will allow a team to respond to change more efficiently and effectively once the project is underway.
Manage the Scope.
Define “The What”
Scope is the “What” of your software project and it’s usually both the starting point and the definition of done. But like all practical endeavors, what was envisioned at the beginning of the project is almost never how things end up. Details change along the way. An effective strategy is not to resist the change, but rather, to adapt to it. You’ll need to manage the “What” every step of the way.
Categorize and Prioritize
To get your project off to a good start it’s best to get your requirements identified, categorized & prioritized. Requirements are best categorized in (2) dimensions: What area of functionality is the requirement associated with and what type of requirement is it? An “Area of Functionality” is usually called a Feature. Some examples of features include account management, search, order placement, order fulfillment, billing & report generation. Every system is different, depending on what it needs to do. This feature list is the high level breakdown of the different aspects of the system. Prioritizing these features is critical for contingency planning. Most of our client projects use the MoSCoW method.
This is a very simple process of assigning each feature a priority - The (4) priorities are: “Must Have”, “Should Have”, “Could Have” and “Won’t Have”. Yes, you even want to explicitly state what the system “Won't Have.” During a project it is not uncommon for a stakeholder to suggest a feature on that list. If you have it prioritized as such, you can simply state that it has already been decided that that feature will not be included (yet). This keeps your project on track. Having the feature list prioritized this way will also allow you to make informed decisions when faced with the need to flex the scope in order to stay on budget or stay on time.
Below is an example of how we storyboard our list of categorized and prioritized requirements. We even use a color coding system to identify which areas need more analysis.
Taken from our software project assessment guide [Get your copy]
Requirements are more detailed aspects of the system that are also known as specifications, or “specs”. Building a requirement inventory, and assigning a “type” is a crucial categorization for the development team. Most project stakeholders think about Functional and Technical requirements but there are other requirement types that are frequently overlooked in the early stages of the project. These include operational, transitional, security and compliance requirements. These latter requirement types often won’t make the first cut unless you explicitly seek them out in your planning process.
A good example of an often-forgotten transitional requirement is the data migration. Moreover, even when data migrations are included in the early planning process, there usually isn’t a clear understanding of how “clean” the old data is or how clean it will be considered for the new system. Transforming the data during the migration can be an extremely tedious, but crucial process that cannot usually be known until the project is well underway. A poorly planned data migration can actually break the system and trigger a fire drill of QA issues that are actually a result of bad data, not bad code. The pitfalls are nearly endless, causing budgets to blow up and timelines to push out.
Manage Technical & External System Risk.
There are many different kinds of software risks to manage during a project but technical risk often has a huge impact. As creative professionals, software developers tend to be optimistic and strive to produce tangible, visible results as soon as possible. Stakeholders encourage this behavior because they want to “see” progress and they will judge the early deliverables by their aesthetic appeal.
Left to only their creative genius and the pressure of stakeholders, most teams will tackle visually rewarding and tactile tasks first, while delaying intangible problems until later. Unfortunately, from a project planning perspective, this is the worst strategy. In particular, underlying technical risks can devastate a project. Moreover, tinkering with visual elements, when too many unknowns are still in play, becomes grossly inefficient. One of the easiest ways to manage technical risk is to use small proof-of-concepts. These should be crude, ugly deliverables that simply prove out the concept and confirm a technical method is going to work. They can be completely throw-away or can be used as a base upon which to build further working code. What’s most important is they quickly confirm that the envisioned technical strategy for a feature is going to work or not.
The most common form of a technical risk item is an integration with another system. In the modern software development world, these integrations are extremely common as specialized SaaS products handle the data processing of focused areas of a business. Building proof-of-concepts with external system Application Program Interfaces (APIs) is a critical early step in your project. Don’t let anyone tell you “interacting with that system’s API is easy”. API implementations vary considerably as integration standards continue to evolve in the industry. Frequently they do not work as described in what turns out to be very outdated documentation.
Manage Quality.
We talk about quality all the time. What’s interesting is how little it is managed during so many software projects. Everyone assumes they’re getting the best quality, and of course, they expect it. But as stakeholders make decisions along the way, what is rarely discussed is the effect each decision will have on quality. Most stakeholders understand the 3 key elements of a project - scope, schedule and budget. But quality is the “hidden” 4th quadrant, “hidden” in the sense that when changes are made to scope, schedule or budget, there is often an impact to quality. This usually takes the form of “we need more scope, but must keep the same timeline and same budget.” When this occurs, there is only one way to balance the equation - less quality.
Now that doesn’t necessarily mean the end final product is particularly poor quality. When building a minimally viable product (MVP), yielding on quality is a viable strategy of managing budget and time-to-market. Less quality can simply mean less time spent testing by the team (and more time spent testing by the actual users). Less Quality Assurance (QA) testing does mean less bugs found prior to deployment, but that’s not always a particular problem or at least not an unmanageable problem. If you manage the quality process throughout the project, you can make wise, informed decisions about where you spend your time ensuring quality and where you can save time & money. Options include adding automated testing, testing on less mobile devices as well as modifying your plan on when to perform both QA and User Acceptance Testing (UAT) tests. You may also opt to support fewer devices, browsers or platforms for your 1.0 release.
Manage the People.
Up for herding cats? Managing people may, in fact, be one of the most difficult aspects of managing a software development project. This includes not only the development team, but the stakeholders as well. This certainly sheds light on the fact that the project manager has the most difficult job in the software world. Knowing enough about the technical aspects of the software development process while mastering the art of communication is no small feat. Team structure is critical to finding the optimal efficiency, especially with a 1.0 release - To keep things simple, we always keep in mind (2) key principles with regards to staffing the team:
# 1 - Avoid the “Mythical Man Month Squeeze”
The Mythical Man Month is basically the idea that if a task or a project takes 40 hours for a single person to complete, then it should take 20 hours for 2 people to complete. There can be some truth to this logic, however it doesn’t work to the Nth degree - Imagine suggesting that 40 people could complete the task in 1 hour! There is a law of diminishing returns with regards to adding people to the project to attempt to squeeze the deadline - and where the lines on the graph cross is different for every project. For every person (or resource) you add to a project, there becomes an “overhead” of communication and management that creates an inefficiency; Sometimes to an absurdly negative degree - imagine trying to coordinate 40 people in the narrow window of 1 hour! Read more about the Mythical Man Month
# 2 Aside from inefficiencies, adding too many people on projects that require creative thinking can quickly cause disagreements and ideology battles that aren’t productive or worth fighting over. We’re big fans of the Three Musketeers Rule
NEVER put more than 3 technical team members on a 1.0 product version. Additionally, we usually limit our project to 1 Senior Engineer - too many cooks stirring the soup can lead to wasteful arguments over minutiae.
When looking to compress the number of people on a team consider the shift left, that is to say, bring your QA testers in early, as analysts in the process. Can you possibly describe the requirements using pseudo code for automated test cases? More importantly, having the QA team know the system and the requirements by working as business analysts early in the project process will make their work testing incredibly more efficient. Don’t underestimate your QA team, they usually know the system better than anyone else; Including Subject Matter Experts (SMEs), Stakeholders and Architects. Why? Because they have to ensure it works properly, and in doing so, they become familiar with all the requirements of the system and all of its expected behaviors.
Manage the Timeline.
Stakeholders are far more critical to the software development process than they sometimes think or even want to be. The more obvious scenario is the demand for scope changes (additional scope). Beyond that, Stakeholders can blow up a project timeline when they don’t fully participate in the project. As an agency, we struggle with this very often. Clients, who are paying a pretty penny to hire our team to build the software for them, often don’t realize the commitment they must make to the project. Subject matter experts and other key stakeholders are critical system users upon whom the entire software development process is hinged. A good system must meet the needs of the users and stakeholders and as requirements “evolve” during the project, questions arise and they need to be answered quickly. In particular, when using agile methods (Iterative and Incremental Development (IID), for example), stakeholders must be highly available or the project timeline - and budget - is doomed for failure. Parkinson’s Law states that the work expands to fill the space allowed to complete the project. What this means is that when timelines get pushed out, it takes more work to complete the exact same tasks (scope). So even without a scope change, pushing out a deadline will require an increased budget. Jazz composer Duke Ellington, who often struggled to complete musical compositions, had it right when he famously said “I don't need time. What I need is a deadline.” Aside from stakeholder involvement, establishing the right cadence of team meetings is critical to keep the project moving fast enough, with the appropriate governance. Likewise, knowing when to circle back with stakeholders at various stages of the project is critical to ensuring results meet expectations. To manage the project effectively, you must carefully balance the right amount of oversight at the right times.
Be sure to use a standard project status report template and having a clear agenda for team check-ins is critical. Typically, an agile standup agenda covers “What’s done, What’s Next, What roadblocks do we face”.
Sound like a lot?
We know the pains of the software development process and like all projects, unknowns are almost certain. Like most endeavors, success is a function of the attitudes, techniques and behaviors we put toward the effort. Although there are many more elements of managing a successful software project, these 5 tactics can have a profound effect on the outcome. Once you get good at these, you can Rinse-and-Repeat to discover further refinements to get your projects done on-time & on-budget.
Now that you have a better understanding of what it takes to manage your project, you need to know exactly what the project entails. The software project assessment guide below comes with insights and key steps you must take before writing a single line of code. Download it today to continue on the path of developing software that will improve your business and avoid the headaches (and loss of $$$) that come with developing software.
