Don't bring a knife to a gunfight.

This expression is primarily about correctly determining the situation and how to approach it.

We see a lot of clients in different situations and the kind of development they need is vastly different. This is why we endeavor to provide the best fit for each project and not just apply a cookie-cutter approach to your project. Here are a couple of common phases we see projects in: idea, screening, concept, development, commercialization, and maintenance. We handle projects in all of these phases, but like bringing a knife to a gunfight, building for the wrong phase can lead to development. The choice is ultimately up to you, but here are a few indicators and particulars for each phase.

Idea

Projects in the ideation phase need a brainstorming partner. There is a kernel of an idea here that needs to be expanded and explored. This may be done with a product team or with your initial stakeholders. This can include things like market fit, persona development, rough budgets, and business process basics at a high level. The goal is to spend a little bit of time figuring out whether or not to spend a lot more time and money.

Screening

Projects in this phase are ready to have more details applied. You will want to work out more potential details from the idea phase and build a blueprint for the project. Successful projects can either go all in on planning upfront or setting a basic roadmap, the choice is up to you as long as your partners are skilled in that workflow. Some projects naturally lend themselves to one extreme or the other. At this phase, you may have engaged a design agency for branding and may be working with software architects and project management teams to determine the details of your project. There may be a small amount of software written here, but it is typically just enough to determine fit and feasibility by the architect team.

Proof of Concept (POC)

This is an optional, but often important phase in software projects. From the technical perspective, this often involves a team taking the core idea and working out enough details into a working system to understand whether this is feasible and what limitations or complications will exist for the planned product. We see a lot of clients in this phase and a common discipline here is to refocus back to the limited scope. Building with too much fidelity here is very costly to software projects.

Development

In the development phase, a whole team is either assembled or is being assembled. A basic understanding of the project deliverables is understood. Design is at least in a usable spot, and the feasibility of the idea has been determined. Often the development isn’t focused on performance or scalability primarily but on just getting to market. Clients in this phase are actively building. Projects that are broken into phases often bring in specialists for certain work items and may scale up or down depending on the critical path to completion.

Commercialization

In this phase, the project has legs and is ready to go to market or significantly scale up. There may be industry-specific legal requirements to hit. You may realize that your architecture needs to be adjusted or some portion of your process needs to be automated at a larger scale. The list here could be pretty long, but this is a great time to hire specialists to consult or build a specific portion short term. You may also benefit from having access to short-term staff augmentation to handle specific work items that are not ongoing. Moving server architecture or performing security audits would be good examples of this.

Maintenance

Once the project is well underway or completed it still has to be maintained. Software in the 21st century is not possible to be “set and forget”. This isn’t due to lower quality, but the increased complexity and pace of the industry require at least some attention regularly. Depending on the size of your team and project or industry cycles this can be a beneficial area contract out. Hiring and onboarding is costly and time-consuming, especially for small teams and we take a lot of the legwork out of that.

There are different ways to break those phases down and you might skip many of them. This isn’t the canonical list, but just to give you an idea. One of the things that often happens for our clients who don’t do this all the time is that they may think they’re in a different phase than they are. 

Sometimes we work with a sole proprietor who has a product idea but also wants to get it right the first time. If we spend too much time polishing the product before getting feedback, time is often wasted. The first half-dozen test users often expose very low-hanging fruit to optimize the customer journey.

Projects that are trying to actively develop before doing proper screening often try to build the ship at sea. You might get lucky in that, but even the most experienced development team will likely fail you if there isn’t a clear set of goals.

Sometimes trying to blend one team to both do maintenance and feature development leads to poor capacity planning and frustration from the company management. Breaking the team into two can be very helpful.

There are many other situations, but hopefully, these get you thinking about where you are with your projects and this saves you a lot of heartache. We always strive to serve the client the best and sometimes that means some healthy pushback (link to do your developer tell you no). Our success is tied to your success and we always try to steer our clients to the right phase and team makeup.

‍