Overview
It is important to view project failures from both the business and technical perspectives. Between the two, three categories of software-development projects emerge: scope-related, team-related, and engagement-related. At FullStack Labs, we have a playbook designed to address the challenges of software-development projects. We have 94 successful projects under our belt, utilizing technologies such as React, React Native, Python, Node.js, Ember, Vue, Angular, Ruby on Rails, and custom frameworks.
Scope-Related
A recent post on Forbes highlighted a few ways that software projects can go south: unclear requirements, misunderstanding the needs of the business, misunderstanding the problem itself, and an inability to manage expectations or reach consensus on priorities were just a few. Another post from Codebots identified similar problems: improper stakeholder expectation management, scope variations, inaccurate estimations. These all boil down to insufficient scope definition and management.
Businesses change, and project scopes expand. But mission creep can be a costly syndrome. And if a project begins without safeguards in place to limit the scope’s expansion, the result is a project that’s never quite finished, and people who are never quite happy.
This may seem like a catch-22: “How can developers know what to develop unless the business tells them, but the business doesn’t know everything they want developed until they interact with the product?”
At FullStack labs, our playbook not only acknowledges the cone of uncertainty but embraces it. The entire first phase in our projects is Design. We start with a roadmap, perform competitive analysis, and develop user personas to represent all stakeholder groups. Doing so makes sure the requirements arising from the competitive landscape are taken into consideration and that groups are not overlooked. Having user personas also makes it much easier to document requirements because it provides a perspective for the requirement as opposed to having to concisely summarize the perspective each time. What follows is a technical discovery where the right software stack is chosen, ensuring technical requirements are adequately captured.
We then produce feature maps (high-level views of the features of your application) which help ensure that dependencies are known. This usually leads to new requirements because stakeholders think of items they forgot to include. In addition, user flows and wireframes are produced — these visual representations are where missing requirements are often identified because subject matter experts get to weigh in on how things are actually done and everyone can provide feedback on the appearance of the application. Developers often get presented requirements but are never given the context within which the requirement needs to be met — user flows and wireframes provide that much-needed context. I have found that once developers are provided the bigger picture, they provide creative input to the business which results in solutions far surpassing initial expectations.
Style concepts and high-fidelity mockups help to make sure the visual elements and branding requirements are captured. Interactive prototypes often surface additional requirements as stakeholders engage visually. At the end of this phase is to develop an estimate and provide a development proposal that increases the estimate’s reliability going into the project. As the backlog changes, the project’s impact is discussed with the product owner, addressing the “inaccurate estimations” project failure reason.
So far, we have addressed the complaints and most of the scope-related issues identified earlier. Our projects are broken down into sprints, and demos occur frequently. Demos allow stakeholders to see what is being developed as it is being developed and provide feedback early. Product owner involvement in managing the backlog leads to understanding the trade-offs involved (avoiding expectation of over-customization) and addresses both change-management and prioritization project failure reasons.
Team-Related
Forbes identified lack of detailed planning and coordination, friction caused by undefined roles, too many hands in the development pot, and working in a silo as software-development project failure reasons. Codebots listed inadequate human resources, poor productivity, and poor quality code as project failure reasons.
Next comes the Develop phase, where we work with the client and the development team to build out key milestones and the release schedule, generating user stories using the personas developed previously. We typically use two-week sprints which are planned in coordination with the client and project team. During the sprint, developers complete user stories (code, test) and QA tests as well. Designers are available to developers if questions arise, and the project manager adds clarification from the customer as needed. Each user story is assigned to a single developer and they work on user stories one at a time, avoiding the “too many hands” issue. We conduct daily stand-ups where each person lists what they completed the prior day, what they are working on today, and any impediments/blockers they are experiencing. This avoids the “working in a silo” issue.
Developers are assigned to projects based on the estimate produced after the Design phase, avoiding failure due to “inadequate human resources.” At FullStack Labs, we use Toggl to track time against each user story in the backlog, ensuring that clients are charged only for the exact amount of time spent. We check reports every day to make sure we are highly productive on projects.
When it comes to product quality, everyone participates:
Designers ensure developers are positioned to build a successful product by following design guidelines meeting the minimum UI/UX Standard of Excellence and providing comprehensive documentation (e.g.: style guide, application diagram, user flows, asset library, prototype tour points).
Developers ensure changes delivered not only uphold the UI/UX Standards of Excellence but also that coding standards are followed: code is minimalistic, clean and obvious to other programmers, self-documenting, linted (checked for programmatic/stylistic errors), refactored, and each project has 95% integration and unit test coverage. In addition, developers minimize long methods, long classes, nested code, and duplication.
Reviewers are responsible for ensuring both sets of standards are adhered to and go a step further to even try breaking the application, blocking anything that does not work properly or meet expectations. Business analysts and project managers may perform reviews after QA to help catch any issues before the business gets the solution.
FullStack Labs’ minimum UI/UX Standard of Excellence includes (but is not limited to) the following:
- Have a strong visual hierarchy.
- Use consistent calls to action.
- Adapt to breakpoints.
- Load efficiently.
- Animate intentionally.
- Account for all states of information.
- Behave consistently and intuitively.
- Have optimized forms.
- Reduce user frustration.
- Use only high-quality assets.
- Be based on research and have a purpose.
- Be designed to move into development.
- Account for edge cases.
Every member of the team is held accountable to these standards and exercises a high degree of ownership. Developers don’t just throw user stories over the fence to QA and hope things turn out well — they work closely with QA. This level of ownership and accountability results in high-quality code and solutions.
Engagement-Related
For a long time, Waterfall projects often resulted in what we used to call the “ivory tower syndrome”: one or a few stakeholders speak on behalf of those ultimately being served by the solution a project creates, but a fundamental disconnect exists. As already mentioned in the Scope-Related section, user flows are key to minimizing that disconnect. Stakeholder and end-user engagement and lack of ownership are still to be addressed.
We work closely with the business during the sprint and have frequent touch-points to make sure everything stays on track. We plan out releases to bring functional solutions to stakeholders sooner than the Waterfall “big bang” approach typically allows. Having feedback earlier in the process allows for course corrections and inclusion of requirements that may have been missed because it is not realistic to anticipate every situation (people are very creative and innovative).
Conclusion
As you can see, having progressive discovery with a SCRUM Agile methodology and a high degree of both ownership and accountability contributes to successful software-development projects by avoiding the most common project failures. At FullStack Labs, software development is at the core of what we do and our passion for delivering high-quality solutions is demonstrated from the very start of a project on through to maintenance.