The top three problems that plague development projects

Rushing the start-up phase

At the launch of a new project, nothing seems impossible! You’re experiencing a honeymoon, enjoying the novelty, the possibilities are endless, and everyone is excited. The risks, on the other hand, are not immediately apparent, and analyzing them would require precious time and effort. Yet it’s precisely at this critical juncture that they must be scrutinized, since risk management is what enables you to anticipate potential problems and adapt your plan. Which isn’t to say that you must worry about every unforeseen development; you just need to do your due diligence.

Unexpected developments: yes, but within reason, please! © iStock.

Often referred to as “Sprint 0”, “Analysis”, “Design”, or “Discovery”, this stage, whatever you call it, is crucial to the rest of your project. This is when you do the groundwork, build solid foundations, think the project through and prepare. It includes making a list of client needs, developing the backlog of tasks to be completed, defining the criteria for stories success, developing wireframes, drafting the test plan, creating environments, completing a feasibility study or UX assessment, etc.

As with any new initiative, we naturally want to grab a project and run with it. And this natural tendency can be spurred on by tight deadlines and an even tighter budget. This is how the first stage of a project, arguably the most important, is often rushed or even skipped. This leads to a lack of overall vision and its corollary, the need to rewrite code.

It’s sort of like building a house with no plan or list of required materials. Next thing you know, you’re moving a wall, or wasting time and money making multiple trips to the hardware store and other suppliers to obtain materials at the last minute.

Solution

Our experience has shown us time and time again that before even beginning a project, you should plan on spending 15 to 20% of the total budget on the preparatory stage. It may seem like a huge investment with very little payback, but nothing is further from the truth! This investment will yield efficiency gains and code-writing savings. Try it, you’ll be convinced!

Unforeseen code refactoring

Adapted from John Cutler.

No matter what your deadline is, any major, unforeseen technological issue will feel like a train wreck.

Refactoring is an integral part of the process at any iteration or stage of development. Refactoring consists in rewriting source code to standardize it and enhance its internal structure, without affecting the outward behaviour of the code. By definition, it excludes adding any new features or correcting bugs. It makes programs easier to understand and maintain, helps to find bugs and speeds programming.

It’s sort of like cleaning out your closets and reorganizing your drawers, to make room for new content that is easier to access.

Solutions

When building a project on existing foundations, either because you’re using someone else’s code or because the source code comes from obsolete technology, set aside time for refactoring.

However, even when starting with a clean slate and building from the ground up, you still have to refactor! Set aside time for refactoring early in the project, and increasingly, throughout the project, as it evolves and gains new features. Build extra time for refactoring in half-way sprints and next-to-last sprints. Our experience has shown that setting aside 10% of the time for refactoring is optimal to ensure the program remains easy to understand and to debug and maintain it. Besides, it speeds up subsequent programming.

Last-minute, unofficial additions and modifications

© Spiria.

While you might think you’ll make the client happy by going beyond the original scope of the project and accepting last-minute changes, the fact is, he’ll be very unhappy if these changes compromise the project or the budget. You need to be honest with the client, document all changes, assess each and every request, and advise the client of any adverse impacts on their budget or deadlines. Even changes with minimal impact should be documented and monitored, since a series of negligible changes can add up to a considerable impact. As they say, the beating of a butterfly’s wings can cause a hurricane.

Solution

Keep a log of changes, just like you keep a log of risks. Ideally, the change log should be on-line and accessible to the client in real-time. Then, prioritize requests so as to avoid jeopardizing the initial objective of the sprints and the project with neat but non-essential enhancements. On larger projects, change requests warrant a regular, weekly meeting, coupled with a bug- and risk-management discussion.

In conclusion, to guarantee that best practices are consistently applied in your digital project, draw on a solid experience gained over a varied project portfolio, communicate effectively and transfer knowledge, in both the development and project management aspects of the project.

I strongly recommend keeping a list of lessons learned and a historical log of problems encountered and their solutions, then sharing these learnings with the entire project community. This will support the continuous improvement of your practices and turn individual and group learning into organisational learning. In the hyper-competitive environment in which we operate, such a pragmatic approach is at the heart of any learning organisation.