Atomic Object builds custom software for our customers. Because of the complexity involved in building a great software product, software development projects are always more difficult to price than a product.
As a result two different strategies for pricing services, such as building software, have traditionally been used by most companies. These are called “Fixed Price” and “Time And Materials”.
A Fixed Price strategy locks in the total price of the project upfront.
- Static Variables: Scope, Cost
- Flexible Variable: Quality
- Assumption: The estimate and plan are correct and will not need to be changed.
- Risk: On Consultant (Responds by inflating cost; may compromise quality if estimates are inaccurate.)
- Effect of New Information: Causes conflict about what’s covered by the scope vs. what requires a change order. New ideas are rarely incorporated.
In this strategy, the vendor is taking on all the financial risk of a project. They have committed to completing the project for a specific price. If they complete the job early, it’s a bonus for the vendor (and you the client has overpaid), if they don’t then the vendor loses. In order to mitigate this risk, they will want to know all that can be known about this project and the risks before it will commit to a fixed price. Read more on Fixed Price vs. Time & Materials vs. FBSC (Fixed-Budget, Scope-Controlled)…
Sometimes you shouldn’t spend resources on a custom software application. And sometimes, you should realize that you aren’t ready to create a software product.
Atomic Object gets hundreds of inquiries every year from people interested in engaging us to build a custom software application or product. Our ultimate goal is help our clients succeed in their business. That means we occasionally recommend deferring custom software, reducing the scope of custom software, or not building custom software at all. Read more on When Not to Build Custom Software…
First time creating a software product? If you are familiar with creating or selling physical products and are looking to get into the software product space, there are a few subtle differences that you should understand. These differences can make a substantial impact on your planning.
The majority of products that exist in the world today are tangible things. They are all around us from the food we eat, cars we drive, houses we live in, and trinkets we buy. As a species, we have been buying and selling physical products for thousands of years. We have internalized and accepted the economics at play (e.g. variable costs, mechanical failure, etc).
But what about software products? Have people internalized the subtle, but important differences? Read more on 3 Ways Software Products are Different from Physical Products…
Are you thinking about developing the next great mobile app? When creating your business strategy you’ll want to know:
- How many potential app users there are?
- What platform you should develop for?
- What apps have the greatest reach?
- What apps generate the most revenue?
The mobile app market is evolving quickly, so the answers to the above questions change frequently. In this blog post, I will report the most recent numbers, and also provide links to resources that you can use to stay up to date with the information you need. Read more on Developing a Mobile App? Some Numbers You’ll Need to Know…
Also posted in Mobile Apps Tagged Android, iOS
You come up with a great idea for an app, and you’re sure it’s going to sell! You plan to have it built and in all of the app stores in a few months — soon after that, you’ll take a vacation or retire on your vast app income. The app, the idea, and the marketing plan will all just form as you go and everything will be perfect.
Wrong! Most of the time, the first idea is never the final idea. It takes work. Read more on Your App Idea Stinks! 3 Steps to Make it Better…
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…