Capabilities /

Three Project Pitfalls (And How To Avoid Them)

By Sean Fitzgibbons | January 5, 2016

After months of vetting vendors, you’ve found a development partner to build your application. It’s all smooth sailing from here, right?

Not exactly.

Here are three common project pitfalls that could easily turn a rapid four-month engagement into a year-long slog…and how to avoid them.

1. Not Understanding Your Dependencies

No matter how clear the vision or simple the end goal may seem, there are hidden dependencies in every development project. These will need to be resolved before work on the application can even begin. Some questions to ask in order to identify such dependencies include:

  • What are all the inputs of your application?
  • Do you control them or rely upon third parties to provide them?
  • Can third parties provide you with the data in a format your development partner can use or will there be work needed to normalize?
  • What are the internal approval processes needed to bring your application live?
  • Do internal technology teams have a say in how an application is developed?
  • Are there security concerns that need resolution first?
  • Does creative design drive your application? Do you have in-house design resources that can be leveraged on your schedule?
  • What level of user testing is adequate to get proper feedback on your application?
  • Should you plan time for substantial revisions after an initial alpha or beta release?

Once all dependencies are identified, you can assign timelines for resolving them and put together a realistic schedule. Your four-month development project might now take six months, but this more realistic timeline allows your development partner to work at full velocity. This way, you’ll be able to avoid hitting dependency blocks and paying for your partner to sit idle while you resolve them.

2.  Not Defining True “MVP” Features

In the process of figuring out the features needed to meet the key requirements of the application, suggestions and input often come in from multiple stakeholders. More bells and whistles may add to the application’s Minimum Viable Product, but often at the cost of core functionality or the development timeline. A good product owner will listen to these ideas, but will ultimately distinguish between core functions and “nice-to-have” add-ons. Later on down the line, the team can then iterate on a backlog of additional features, but the first priority is getting core MVP functionality working properly first. 

3. Internal Stakeholder Misalignment

Assessing design and functionality before it goes into development is critical to avoiding messy issues down the road, from change requests to late-phase functionality overhauls.

A key phase for every project is User Acceptance Testing (UAT), the period during which the delivered application is reviewed and approved by stakeholders before going live. UAT may be the first time stakeholders take a close look at what has been developed and often leads to requests for new features or changes. The basis of UAT should be the designs and specifications that were signed off before development on the project began. However, it can sometimes be difficult for internal stakeholders to fully grasp how a web application functions based on design comps and specifications alone. It is important to understand your senior stakeholders, as well as how they have historically given feedback, when planning your schedule.

To mitigate these instances, consider releasing prototypes of your application throughout the development process. This will give stakeholders limited sets of functionality to review early enough so that changes can be made without jeopardizing your timeline. Alternately, anticipating in advance that there may be larger changes out of UAT, a project should always budget in additional buffer time between UAT and Go Live to account for updates. Without a buffer, a project risks being rapidly derailed in UAT if any feature has not been developed to meet expectations.

Application development can be complex with multiple teams engaged. Assumptions and ambiguity can throw even the best developers off track. A guiding principle to help avoid pitfalls is to start with open communication with stakeholders and a clear definition on the application being delivered. Continuing to validate expectations throughout the project with both stakeholders and development partners helps raise issues early and keeps everyone aligned around a successful project and its goals.

→ Need help getting your new development project off the ground? Get in touch.


4 Types of Transformation That Can Help Your Business

While transformation is the word on everyone’s lips these days, how to achieve that transformation often lies behind a veil…

Read more

Software Self Defense 101: Improving Your Technical Estimates

[caption id="attachment_458" align="aligncenter" width="570"] photo credit J.King, ModernAnalyst.Com[/caption] Estimates are a necessary evil in every development organization. You have…

Read more

8 Ingredients for Crafting a Service Level Agreement

Whether augmenting your current development team or leveraging third-party vendor resources for application management, a clearly defined Service Level Agreement …

Read more
// // //