If you or your organization is ready to invest thousands of dollars on building a piece of software, you hopefully already have a good idea of who your users are and how they will interact with your product. You could be a subject matter expert, or your company may be a leader in the field that your project is targeted towards, putting you in a great position to provide background on what the software ought to do and how it should be used. What you’re looking for is a top-notch team ready to hit the ground running and build your software.
In a previous post, I discussed how Atomic Object engages with our clients in a phase of Research, Design, and Planning (RDP) at the beginning of each project to help define and refine a software product. If you’re well-prepared and grounded in your field, it could be difficult to see how this work could be worthwhile for your project, and skipping RDP may seem like a great way to save some money towards feature development. However, just a bit of time up front can pay off in a big way during the build phase of your product. Here are several ways an RDP phase can benefit a project. Read more on Strengthen your Software Investment with Research, Design, and Planning…
Human-Centered Design (HCD) practices help companies develop innovative product concepts. From my experience, extending HCD practices inward to include a company’s information technology team increases the chances for success.
What is Human-Centered Design?
IDEO (a leading global design consultancy) recognizes that HCD involves viewing solutions through the lenses of Desirability, Feasibility, and Viability and building products that live at the intersection of all three lenses.
Read more on A Human-Centered Design Approach to Involving IT in Product Development…
When you are developing initial requirements for a new software product development project, you may find yourself questioning the appropriate level of detail to provide for specifications.
You may feel compelled to provide a high degree of specificity so the development team can create an accurate estimate of cost and time to build the defined solution. You may feel worried that if you miss something in the software requirements, the project — or even you — may be viewed as a failure. The good news is that you can loosen up! There is a better way to develop requirements, and it doesn’t include specifying every detail at the start of the project.
Detailed Specifications – Too Much Definition, Too Soon
The first step is to realize you probably should not be creating a detailed set of functional or technical specifications for a development team to build. It’s usually too early to focus on detailed specifications before the development team has an opportunity to creatively engage in the project at a broader level — including business and user motivations. Providing detailed functional and technical specifications too early can create a false sense that the problem or opportunity is completely understood, which can result in missed opportunities or inaccurate project plans.
Read more on Creating High-Value, User-Focused Software Requirements…
Eric Ries defines a Minimum Viable Product (MVP) as
“…a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
An MVP usually targets early adopters and includes only the minimum amount of features to validate your value proposition hypotheses.
The practice of starting with an MVP is a lean startup tactic. To execute an MVP well, I suggest you study the principles behind it and the Lean Startup Methodology as a whole. Understanding Lean Startup principles will also be a great help as you build your company.
When Less Is More
Through years of experience helping clients build products with Atomic Object, I’ve found most product managers and entrepreneurs tend to overbuild their first product release. This is often comes from a fear of underbuilding – they want to know that they’re product is compelling enough for their users, and they don’t want to give competitors a chance to leap-frog them. I also believe overbuilding can be partially motived from another fear — a subconscious desire to put off the release and the prospect that your idea might fail.
Read more on Less Is More – 4 Benefits of Starting with a Minimum Viable Product…
So, you’ve decided to rewrite your software. The entire team is ecstatic. No one will have to deal with the old, hard-to-use, painful-to-extend mess anymore.
Since you already have working legacy software, you have the perfect specification for the new product. Planning what to do should be easy right? Not exactly. Creating software from scratch is all about “what can be,” but rewriting software has to start with a clear understanding of “what is.” And your existing application probably does far more than you think.
Before you jump in with both feet, take time to do some research. The better your information, the better your software will serve your users, and the happier everyone will be at the end of the day. Read more on 2 Essentials of Planning a Software Rewrite…
When solving internal business needs, should you buy an existing software solution or build a custom solution?
The biggest advantage of custom software is the ability to innovate and invent. That’s why custom software is commonly created for new products and innovation projects.
But if you’re looking to leverage software for a common operation or management need (ERP, CRM, financial, compliance, etc.), your choice is not so simple. If an existing viable software solution exists, you must decide whether to build or buy.
Here are some advantages of each option. Obviously, every situation is unique, but this should help you start evaluating your options.
Read more on Enterprise Software – Build or Buy?…
The worst possible budget for a project is zero. If you have no funds or no time, you have no power to build anything worthwhile. That’s not a surprise to anyone – no one likes working under absurd constraints.
The second worst possible budget is unlimited.
Read more on An Unlimited Budget Is Almost as Bad as No Budget…
Atomic creates custom software for our clients. Our work ranges from greenfield web application development to creating backend data-centric applications. In most projects, we work with multiple technologies and we integrate with other systems. We’re not experts in every technology, but we’re experts at becoming experts with any technology we work with.
Read more on Fixed-Budget, Fixed-Scope, High-Quality Custom Software…
Vendors may use the phrase “time and materials” (t&m) to describe how they engage in projects and invoice their clients.
The phrase t&m has been laid to rest at Atomic for several reasons. First, the phrase doesn’t accurately describe how we engage with our clients. At Atomic, we certainly don’t work without profit. And we have an innate desire to be more efficient.
Read more on Time and Materials is Dead…
We do a lot of things when we meet potential clients. Assuming we mutually determine that Atomic is a good match to the project, the conversation eventually ends up at how much the project will cost. The shallow answer (“as little as possible”) is correct, but not very useful. We put the following outline together to suggest a more actionable approach that avoids a major risk and achieves the goal of maximizing the product created for our client’s investment.
1. Know the Impact of Your Project
Our clients generally build software to generate revenues or reduce expenses. If the client doesn’t know how much money can be earned or saved by a successful project, then it will be difficult to determine whether the project makes business sense regardless of what it might cost. Building a model requires understanding the business and the project being considered. Sometimes we work as consultants to help with this work. Read more on Getting the Most for Your Money…