10 Reasons Your Application Development Project Will Fail
Keeping your developer out of the ditch and your project on track.
- Keven M.Thibeault
According to a 2010 survey of 200 companies, 53% of IT development projects failed or were seriously challenged. That’s a success rate of only 47% — slightly worse then current rate of divorce in the US!
Are you a business owner or manager getting ready to invest in a new mobile application, website, ipad app, or other technology? Then you need to know how to improve your odds and make sure your project doesn’t fail.
You should understand the underlying causes of failure, learn how to counter these common pitfalls, and finally – take action to stack the odds back in your favor.
There are two main roles that contribute to the health of any project. The first player is the business owner. The business owner sees the market or organizational need (problem) and has the vision for the product (solution). They use their experience and business prowess to imagine brand new products or improve current platforms.
The other major player is the developer or development team. Geeky developers by nature love to build solutions to their clients’ problems that impress each other and their clients. Developers take pride in constructing and inventing dynamic products that educate, entertain, or otherwise serve people in the real world.
On the surface, the two seem like a marriage made in heaven. One generates compelling ideas while the other brings these ideas to life. You would think that more often than not, business owner/developer relationships would go smoothly and enjoy harmonious bliss. We only wish this were true. More often than not, we see disjointed relationships, flimsy business plans, and unengaged project management affecting development efforts that otherwise should have been a huge success — on paper at least. In reality it is primarily the business owner/developer relationship that drives the success or failure of any technical project.
Those familiar with software development will recognize these common sentiments:
From the Business Owner: “The developer didn’t get my vision, my process, or understand my company’s and or consumers needs. They missed so many obvious details.”
From the Developer: “The business owner didn’t tell me everything I needed to know, so I was guessing most of the time and I was totally caught off guard when he was angry and disappointed in the end product. I’m not a mind-reader.”
When projects fail, who takes the blame? Generally the developer does. After all, it is the developer that seems to hold all the cards, right? As business owners, we typically assume:
• they have all the required expertise needed in all technologies or entities connected to the product
• they get it; they completely understand our business and our vision
• they know all our business rules and requirements and can apply good common sense to fill in the blanks when they lack necessary detail
• they are intimately familiar with our industry, our markets, our competitors, our corporate culture, our language, and our product offering
• they can accurately predict all technical risks and costs at the beginning of the project
• they can intuit the business meaning of every detail in the design, whether it is documented or not
• they can naturally work well with hurried, impatient business owners
While it is true that the more experienced the developer the better the resulting product, no developer can claim all of these qualities. This is especially true as it relates to custom development which is by definition new, innovative, and full of exciting unknowns.
So how do you keep your deadlines, budgets, and project plans safe from disaster? How do you help yourself manage common threats and risks?
You have to actively help your developer and your project succeed. It is possible to manage the pressures of limited funding and aggressive delivery dates if you are smart, flexible, reasonable, and commit to a thoughtful strategy and action plan to mitigate common development threats.
Above all you must commit to staying engaged throughout the project, constantly collaborating with your developer to avoid the common mistakes. So what are the top ten reasons your project will fail?
1. You design your application in a vacuum with little or no product strategy.
When car makers get ready to invest millions in a new model, they research the market to answer fundamental questions such as What is selling now? What is not selling and why? What is my competitor offering? Who is buying their products? How can we do better? If we made something new, would anyone buy it, and who would we market to? How much should we charge? What designs are most appealing? What are the current trends in features, prices, colors, etc. ?
Just as with billion dollar automotive investments, you too must give careful thought to your software application and its position in the market. You will invest in development, but also need to plan to spend money and time on marketing and promotion to let the world know about it. Very few products take off virally. Yes it is possible to get free mention on Engadget or other powerful blogs, but you cannot count on it. Most sites and applications need social media advertising at the very least on Facebook, Linkedin or other sites. Others, depending on budgets rely on cable, TV/movie product placement, celebrity endorsements, traditional media, and good PR. To keep from failing, make sure you have a solid product strategy in place before you spend a single dime on development.
2. You give your dev team little to no background on your industry, niche, market, or company.
Any good developer is busy. This means they have many clients building apps for consumer and business markets and cannot be an expert in everything. So unless you are lucky enough to find a developer that knows your industry and company intimately, plan to spend time to educate them. This means giving them your marketing materials, web resources for industry background, and several meetings to get them oriented. You could avoid this step, but do so at your own peril. If you don’t take the time to do this, they will be lacking in their design efforts. They need to know your target audience and the main value you bring. They can help you capture the biggest opportunity if they are knowledgeable in your markets. ”But these are marketing disciplines” you say, “why should our developer care?” They should care because as they build your product, they can quickly assess how it fits in the product market at large and add unique differentiators. At the very least they can me sure the branding, look and feel stand out from your competition, and appeal to your target market.
For example, if you are building a dating site for outdoorsy singles, make sure you educate the developer on the lifestyle of your target audience. Your developer then, might surprise you and suggest a new expanded design that includes a new plan for integration with premier camping, hiking, cycling, and boating sites for cross promotion. Your site can help your users find BOTH a date AND a great place to go this weekend that appeals to both dating profiles. Your site can co-register users while your partner sites share in increased revenues.
3. You rush through the design process
This is likely the largest source of aggravation for all sides. We want an appealing and effective product design and know that as soon as it is finished, we can get on with the job of actually building the product. This excitement can cause us to push the process along too quickly. In our eagerness to get to the development phase, we shortchange ourselves. We miss important details that our users invariably find after we launch. Ouch – how did we miss that one?! We may or may not blame the developer but it doesn’t matter at this point. Our users have shared negative ratings, sales dip or crash, and we are faced with picking up the pieces.
To make sure you don’t miss important design details have your developer prepare screen mockups. Don’t assume that wireframes are enough, they are not. Wireframes are basic black and white squares, rectangle, and words with dimensions, and lack good detail. Screen mockups are needed too. They are usually created in Adobe Illustrator and show final end results documented with fonts, colors, sample pictures, backgrounds and the like. These take time to build, and require investment to cover costs. Make that investment. If you don’t you will be setting yourself up for uncomfortable conversations later on during endless fixes and redesign. Even if your developer is comfortable to start the project without these designs, you should insist he uses these, and you should be willing to pay for them. As a rule, the requirements and design portion of your project should be about 30% of the total cost. The others being 30% for development, 30% for testing, and 10% for deployment to real production environments.
4. You assume your dev team thoroughly and properly tests your product for functionality before giving you a first look
Don’t assume your developer thoroughly tested anything. They should, but they often do not. Developers by nature are inventors. They create. They are stimulated by creative problem solving. They do NOT like to test. They do it but they do not like it. Testing is seen as mundane and anything BUT creative. Often you will ask to see the current development version of a product in the very early stages. In the exciting rush to build the prototype for client review, developers will cut corners on testing to meet a deadline. Good developers will have a separate staff that does the testing. This is huge. Go with them.
The saying, you cannot change a leopards spots applies here. So how do you manage expectations and avoid failure? First understand there are always hundreds of moving parts in any development project, even if there is only one person doing everything! Just because something does not work, or does not work as expected, does not mean the developer has not given adequate effort to this feature. They may have had a fully and correctly functioning version on a different server, but when moving it to the client server something broke. They may be lacking good test data. Or just need to finish an unfinished thread of code.
In order to minimize disappointment here, it is important to document what you wish to see, before you view the prototype. It is quite simple – give your developer testing criteria. Just create a list of features you would like to see demonstrated first, and the results you expect in the demonstration. For example, your list might look like this:
- Create a new profile; user name = John_smith, password = pass1234, mobile phone number = 555-1234, profile type = “free”, upload my picture
- Login (john_smith / pass1234) – displays welcome screen with links to “My Profile” now visible
- Create an article to share with my friends on the site, with pictures or videos
- Rate and comment on my friends articles, want to use five star rating, comment via text box, share on FB or twitter.
Giving simple testing criteria gives your developer the chance to knock it out of the park the first time. All parties will be happier, and your product will get done sooner with higher quality.
5. You decide to avoid the time and cost of a stress test so you can launch sooner
Your market and investors are waiting. The design is done. The data is loaded. The product looks great and performs perfectly. So it is time to launch, right? No way. Not every product requires extensive load testing, but in the day of connected mobile products and consumer web applications, most really do. Don’t skimp here. If you expect 10,000 visitors a day when you launch, test how the servers respond when you simulate 50,000 users in two hours. If your site allows users to upload video, and your encoding server is expecting 100 five minute videos a day, simulate 1,000 videos. The weakest part of your platform will magically and instantly reveal itself. You will have time to tune and adjust your platform. You will avoid failure and avoid costly and embarrassing performance problems giving your product a real shot at a good first impression.
One of today’s most popular desktop telephone calling and video conference products which has millions of users is failing with one of their mobile products. Users can install the mobile version on their phones, but then cannot log in! The product works great on the desktop, but not on all mobile platforms. They did not properly test on all supported devices, and are specifically having issues supporting users on the Android platform with some devices. The negative feedback has been streaming in for months. They would have been better off with nothing at this point.
6. Your dev team has no easy way to communicate progress or complications, or worse, is just bad at communication in general.
Avoid project failure and avoid costly surprises, keep engaged with your team answering design questions, and keep up to date with progress.
Just as in any relationship, the key to happiness is clear, honest, frequent communication. Technology partnerships are no different. Avert failure or serious challenges by making sure your developer has good general communication skills at the start. It is vital to interview the project manager who will be managing your product development during the sales process. This person should be experienced and able to talk freely about the dev team and their process for client communications.
In addition, make sure your team uses a web based project management tool to track milestones, bugs, enhancement, and general communication between stakeholders, developers, and the testing team. Most good developers do, but not all for sure. You must know what is going on and help during any difficulties. The alternative is to rely on an impractical and time consuming series of regular status meetings. Meetings are important, and certainly there is nothing wrong with status meetings, but they should not be the primary method of team communication. With Basecamp, Bugzilla, Trak, available for free or close to free you have some very useful options. There are many good team communication apps to employ, and if your developer is not already using one, insist that they do.
7. Your budget is not flexible
Projects can fail when owners and developers cannot accurately predict the time and cost required to build the product. The owner can run out of available funding in the middle of a project leaving the developer with a choice to absorb the increase or not. If no compromise can be made the relationship quickly sours and could result a stalemate where no more funding is found and no more work is being done. The product can die on the operating table and the business relationship can devolve into a place no one wants, including threats for legal remedies.
Even with the most experienced developers, estimating projects is more an art than a science. No developer ever bids on a project with 100% certainty they have correctly planned all hours required. They make an educated guess based on experience and some estimating tools. So the price and the cost are always somewhat fluid. In addition, the developer may have made concessions in the contract negotiations that leave little room for error. With bigger projects especially, developers often cannot predict time needed to cover loosely defined requirements or integrations. And in many cases, requirements change or grow and necessitate more development to support them. When scope increases, be ready to add more funding to support the change. This is common and is a contingency that should be planned for. Keeping an eye on budgets means making decisions together with the developer on how to handle unplanned changes.
8. You choose junior level resources
The needs and resources of each business owner is different. Many times only a fraction of an otherwise reasonable budget is available to fund product development. In these situations the business owner has three options: 1. wait until more funding can be made available, 2. reduce the scope of the project to match funding, or 3. find junior resources at low costs to do the project. This last option seems very appealing to many owners because by using lower cost resources, they can now seemingly afford the “five bedroom vacation home” for the mere cost of a mobile home.
It should be no surprise that common sense dictates that the result of choosing cheaper resources is higher, not lower overall costs, in the long run. Your project is at a much greater risk of failure if you have “newbies” designing and building due to the sheer lack of real world experience. When considering heart surgery, who would you prefer does the operation? You want the veteran doctor who has done 1,000 procedures, NOT the new intern. The reason is because the veteran has seen it all and knows how to handle the curveballs that inevitably come along. The same rule applies to custom software development. There will always be unknown challenges, and an experienced professional with a healthy business is your best friend, even if they cost a bit more.
9. You don’t take adequate time to explain your vision to your developer
It is amazing but true. Developers often hear only the bare minimum about the product. Business owners are by nature are driven, high energy, innovative, very busy, and lacking in patience. When it comes time to sit down with the developer and tell the story of the product and its value in the market, they often leave out rich color and subtle detail. They may not feel comfortable going into great detail or understand the value of the exercise to the developer. Or they might feel it is simply not needed and therefor a waste of valuable time. Nothing could be further from the truth.
Great products are the result of solid research, great imagination, and tight collaboration of talented professionals. It is critical to take the time to share with the development team, the whole vision in as much detail and enthusiasm as possible. The project is being built by real people. If those people share the business owner’s enthusiasm and power, the product will shine. Instead of delivering only what is asked for, they will indeed over-deliver, adding more than was ever imagined in the beginning.
10. You didn’t plan for change during the project.
Things change over time, if your project is 10-15 weeks long as most are, you will think of new ideas throughout the project. This is okay and natural. Make sure your developer is flexible, but also make sure you proactively plan for change. Don’t assume your end result will mirror the original design. IT NEVER DOES. Also make sure you have a prototype to play with early in the project plan! This will give you new ideas and jog your thinking. You will come up with changes. And it is critical to have a plan to deal with change. If your new ideas change the scope, then change the deadline if needed and also change the budget. Don’t get stuck in a corner with a developer who adds cost when you change the scope, and doesn’t tell you until later in the project. Agree together on a plan for change. All changes should be logged and priortitized. Stick to your original plan if you want to, but if a new enhancement is needed, then you have to be willing to lengthen the project and increase the cost. When you find that you and the developer both missed a critical component of the product in the design process, be ready to adjust the scope.
Don’t make your developer wrong for not predicting the change, even if it seems obvious to you. Work with them to plan if and when the change will be added to the project. If you want to keep the budget and timing per the original plan, you can always adopt the change in a future version of your app.
About the author
Keven M. Thibeault has been developing applications since 1990. He now serves as principal and CEO at Logical Design Database Solutions based in Boston, Mass, and provides product strategy and expert application development services for web, mobile, tablet, and enterprise platforms targeting startups, interactive agencies, and technology clients.
1 2010 IT Project Success Survey, drdobbs.com
2 For a general definition of “failure”, consider these variables:
TIMING: TOO LATE- finished weeks or months after the project plan called for, or missed several critical deadlines during the project
COST: BLOWN BUDGET – delivered significantly over original cost estimates
QUALITY: DOA – dead on arrival, the product performed badly, did not meet most of the stakeholders needs, or had to be rescued by another team
3 the term “product” below refers to a website, a mobile website, a widget, a PC application, a tablet application, or a mobile application