You have a great idea, something that will bring customers in the door and help establish a broad audience for your products or services. There’s only one problem—you don’t have the in-house resources to turn this idea into reality. This is where Gigster comes in, pulling together a development team to make those visions reality.
Here are nine points to help you determine what kind of help you need, and reduce the chances that things will go awry.
Design At the Outset
In any software project, there are three distinct phases: design, development and maintenance. Yet of these, design often gets short shrift.
The impulse to plunge into code is a strong one. Resist that urge. Design is where you, as the client, determine what your own needs are, rather than what may be most convenient for developers to build. Design determines functionality. It establishes the look and feel. Moreover, design sets expectations of how long the project should take and how much it should cost.
Without design, you are reliant upon the programmer to design your application. This isn’t necessarily a good thing (Figure 1).
Figure 1. Why good programmers often make poor designers—piling on data crowds the visual space here.
It’s imperative to separate design and development into two distinct phases: the first to design what you are trying to build, the second to build what you’ve designed. Not only will it ensure that you know what you’re getting, but will also make it easier to sell to other stakeholders within your organization.
Set Budget and Schedule Early
The preflight design phase also allows you to identify the scope of the project and estimate the level of complexity involved. This in turn helps you estimate a budget and schedule for development.
A program to record the tracking of birds in a national park is pretty straightforward—store an IP address and a GPS code in a database and provide a way of updating that database. It can be written in a couple of weeks.
A program to visually identify birds from camera photos, on the other hand, is a major effort in visual pattern recognition and machine learning, which could take a team of developers years to complete. The design phase becomes necessary to scope out the project, and estimate the level of complexity that’s really involved.
Before you enter into negotiations with a development firm, you should know what you can afford. As with any other custom work, if you needed it yesterday, you will pay extra. If you’re not as time-sensitive, most development shops will work to hit that schedule, because they want your repeat business.
With a two-phase design/development engagement, you can use the less expensive design period to determine your overall budget cost, prior to engaging your developers.
Hire a Product Manager
Even the best development houses need a liaison from the client’s side. This person—the product manager—plays a number of roles. They clarify the design. They make decisions about functional priorities, review progress, and work with scrum teams to keep the application on schedule. They buy off on user stories, and determine completion.
Make sure to have a product manager in place at the beginning. They may wear other hats as well—business analyst, client scrum-master, arbiter—but their primary role is to represent your company to the development team.
If possible, have a second product manager shadow the first. The longer a project goes, the higher the chance that the first manager will have to bow out, and without an understudy, such an event can prove costly, especially as it will take a while to get a new manager up to speed.
Determine Your Dev and Data Environment
What does your development look like? Your company will likely have made an investment in standardizing on a certain stack: Java, C++, C#, Node, PHP, Apache and so forth. It’s the technology that your existing developers know.
In an era of services, this also extends to a deeper understanding of the database environments you’re working with, as well as whether you’re working with scalable clusters, system virtualization, and NoSQL data systems.
Establish which development and data stacks you will use in the design phase. If you are working with a stack that is unfamiliar to your company, even if it is familiar to the consultants, scale the project down to a skunkworks project to test integration with your existing systems.
Too often, companies have bet the server farm on unproven technology without doing due diligence, and end up losing time, political capital, market opportunity, and significant money. This is especially true when the technology is considered bleeding edge.
It may be the hot buzzword of the day, but proceed with caution. A good rule of thumb is to adopt a technology only after its hype cycle has peaked and it has resurfaced as a stable technology—a process that usually takes between two and three years.
As important, make sure that your proposed development shop understands the technology in question. Ask to interview their engineers, and cultivate acquaintances familiar with the technology who can tell whether the developers really understand their stuff.
Review the proposed development team members’ resumés, and be wary of bait-and-switch tactics where a “name” developer may be brought in to interview but then have only a very peripheral role (if any) in the actual production. Corporate references should also be followed up.
Understand Your Logistics
Say your company’s headquarters is in Boston, your development team is in Hyderabad, India, and you have a corporate demo the day after tomorrow. The India testing team discovers a critical programming bug in random testing that will cause the application to blue-screen one time in ten.
Chances are pretty good you won’t even know about it until eight to ten hours after it’s found, at which point the critical people in India have gone home for the night, and the possibility of introducing a fix before the demo drops dramatically.
This communication latency is one of the biggest causes of delays with most software projects. As the product champion, you have to ask yourself whether the logistical effort to maintain widely distributed development teams is worth the cost benefits.
Is a project mission critical? Maybe working with a team closer to home makes sense, even if they are more expensive. If the project can be managed with relatively little oversight (though this is rarely the case), then offshoring might be the way to go.
What is important here is that you understand communication logistics early on. Much of this can be facilitated by coming to an agreement about code repositories, scrum packages, documentation management, messaging software, and expectations about how and when communication is facilitated.
Yet another benefit of good design wireframes is that they make it much easier to determine if a project has been completed to everyone’s satisfaction. Good wireframes are like the picture on the cover of a puzzle box. They provide a quick visual standard that everyone can reference, and reduce scope-creep.
Most wireframes are deliberately designed to look hand-drawn, in order to focus attention on workflow rather than the finished visual design of the application. Many application designers place such wireframes into a PowerPoint presentation, with links at each workflow point taking it to the appropriate part of the application.
Such wireframes not only guide developers in putting together the application, but also serve as one way to determine what constitutes done. If a given workflow consistently matches the presentation workflow with live data (and passes tests for data consistency and error handling), then the workflow is complete.
At the same time, projects evolve. No application will completely satisfy its initial design—pieces are removed, new technologies make certain parts obsolete, usability tests indicate a need for change. This means that any application in development should also incorporate a change management strategy.
Most development shops have specific contingencies in place when scope changes due to client requests, and you should ensure that similar stipulations are in place to manage scope narrowing. Empower your program manager to approve scope changes coming from your organization as well, as it’s effectively his or her budget that takes the hit.
Life After Shipping
Most software development is like having a baby—there’s an immense amount of work involved as the software matures up to the point of delivery, yet this only accounts for the proverbial nine months. The final software will be around for years. As part of the design process you should ask: “What happens after it ships?”
Understand the terms of engagement. Who is responsible for technical support? What if bugs surface after the application ships? How long does such maintenance coverage last?
Maintenance contracts should be considered as a separate contract up front. In addition, if the software is complex, you may need training to make the best use of it, along with documentation. Training, documentation, and maintenance should not be afterthoughts. They are time-consuming and difficult to produce and need to be updated as the software itself changes.
After taking all of this into account, one key “bonus” question should always be asked:
Does the project make sense to do in the first place?
Even before you bring in designers, ask yourself (and other stakeholders in the company) whether it makes sense to do the project in the first place. Too many useless projects are taken to completion because of the regret of sunk costs. These costs could have been avoided if this question was asked repeatedly at strategic points in the overall lifecycle.
An application should be written to accomplish one or more business objectives. Figure out how much value associated with achieving each of those business objectives should be. If the total cost of ownership exceeds that amount, then it’s time to re-evaluate your goals. Either revamp the design of the application to meet more profitable goals, or kill the project.
Additionally, there’s a secret about software development. A handful of solid developers can usually code complex software within a few months, given a clear design and diligent management. Fifty mediocre developers will take a year or more.
The reason for this is that the more people that you have involved, the more time and energy is spent on coordination. When there is a lack of effective design, this becomes even more of a problem.
Getting the Green Light
Your company should continue to evolve technologically to stay competitive. Gigster wants to help you get the best technology for your money. By doing some homework up front, investing in early design, and refining your vision to see how it fits into the overall needs of your company, you can get a far better return on your investment.
If you’re thinking about hiring a development team, get in touch with Gigster today.