• Home
  • Archive by category 'Development'

Archive for ‘Development’

Teach yourself how to code with Codeacademy.com

If you are learning to code, and need a more interactive tool to teach the basics, check out Codeacademy.

Jump in and start your first lesson for free.  Javascript, PHP, HTML, and more.  When you visit Codecademy.com  you are asked to begin coding on the home page, which involves printing out and finding the length (in letters) of your name. After a few such lessons, the site prompts you to create an account.   If you dont, your progress goes down the chute, so register!

Founded by Zac Simms and Ryan Bubinski, there is no plan on monetization just yet, but the site is off to a great start.

 

Best Windows tablets of 2011

By Jon M Simpson, Logical Design, April 25, 2011

As Steve Ballmer continues to pay for ignoring the great ideas of his rivals in this mobile market explosion, there are a handful of tablet manufacturers that believe in the value of Windows and are continuing to manufacture tablets for the OS – very good ones at that.

In spite of the iPad’s monstrous success, factors such as Apple’s notoriously closed ecosystem and Jobs’ rejection of Flash are allowing the competition to stay hot in pursuit. Add in the still shaky Android OS and the delay of Honeycomb, and Ballmer’s decisions may one day prove forgivable – well okay, let’s not get ahead of ourselves…

Sometime in late 2012 Microsoft is set to finally release an OS specifically for tablets, but in the mean time there are some very impressive Windows 7 tablet offerings this year that cater to everything from the ultra-mobile to the power hungry:

The titan: Asus Eee EP121
With both size (12’) and power (Intel i5 and 4GB ram), this Wacom compatible slate tablet is the workhorse of this years’ class of Windows tablets. It comes with a light-weight wireless keyboard, 2 megapixel web camera, an AFFS display, and the hardware to handle the rigors of the likes of Adobe’s Creative Suite, Netflix and Autocad. In spite of its sleek and sexy design, it is a bit beefy at 2.5lbs and has a meager battery life of 3.5 hours. But this is geared towards real computer work and a small trade off for the size, power and Wacom pen.

The midget: Viliv’s X70
For the ultra-mobile, this beautifully manufactured, 1 pound wonder from Viliv comes with a 7 inch screen, a 5 hour battery life, and features a nearly instant-on capability (less than 5 seconds), 1024 x 600 resolution, 802.11n Wi-Fi, Bluetooth, 3G HSPA, WiMax, Verizon’s EV-DO, a dual camera and GPS. With 2GB of ram and 32GB drive, this puppy is perfect for content consumption.

A few noteworthy runner-ups are the yet to be released Lenovo IdeaPad, the Motion CL900 and currently unnamed Fujitsu. Among these Lenovo excels, with touch friendly dual viewing panes (one for work and one for play) and its Morgan’s Touch digitized layer and pen. Though release is set for sometime in May, at 499, it should be well worth the wait.

It is hard to predict where all of this is headed and what OS will dominate the tablet market of the future. But one thing we can be sure of, with offerings such as these emerging at a feverish pace, there is already a very clear winner – the consumer.

 

Real Life Terminator : Predator – A Tracking Software that Learns

Remember the erie red view of the Terminator eye? It scanned its view and and found the object of interest, registering it and indexing it for use later. This view of the future is less fiction than reality. Thanks to a unique algorithm developed by Czech PHD student, Zdenek Kalal email: [email protected] .

In this video the system tracks his eye, on and off the screen, and can learn to view and track objects from multiple angles, see the Panda bear later in the video for a fascinating demonstration of technology.

 

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!

Project Disaster

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.

Follow logicaldesigndb on Twitter

About the author

Keven Thibeault

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

 

More Articles Like This: “Should You Trust Your Project Plan?

 

 

Want to download your own copy?

For a limited time, you may download a FREE version of this white paper.
Just sign up with your email on this form .  You will receive a download link after you confirm your email address.

 

Should you trust your project plan?

Should you ever trust your project plan?

Keeping your developer out of the ditch and your project on track.

- Keven M.Thibeault

Should you ever trust your project plan?  In our experience the answer is NO WAY.   You are guaranteed a surprise every time.  So let’s tackle the obvious.  Chances are your team will either overestimate or underestimate some or all of the following

  1. The time needed for requirements, design, and team reviews
  2. The level of support from business owners and users
  3. The complexity of integration with other platforms
  4. The quality of your data
  5. The effort and time needed to test
  6. The time needed to develop the code
  7. The readiness of your production systems
  8. The capabilities of your development team
  9. The strength of your vendor’s products
  10. The features your users really want or need

 

Planning how long it takes to build your application, (and its related cost) is incredibly challenging indeed.  The development world continues to change and we have to adapt how we plan our projects accordingly.

 

The enormous pace of change in development today has disrupted how software products are built and invalidated most conventional planning methods and historical comparisons.  Chances are your plan is off by a factor 50% or more in either direction.

 

And this is not always a bad thing by the way.  The good news is that many tasks now often take far less time to execute, including design, development, and deployment.   Our insatiable demand for technology has forever shaped how technology is supplied to us.  Market forces have shrunk and commoditized nearly every facet of application development.

 

Dedicated servers can now be provisioned in hours or even minutes with companies such as Rack Space, Godaddy, and Grid.  Code sharing sites with sample snippets like Sitepoint and PHPBuilder allow developers to search, cut, paste, and configure, (vs. customize), their way to staggering levels of functionality and sophistication.  Plugins and modules for CMS platforms such as Joomla, Wordpress, or Drupal number in the thousands and give you the ability to add capabilities in minutes.  And outsourcing mega-portals such as Elance, Odesk, and Guru give a project manager near instant access to designers, testers, business plan writers, and developers complete with virtual team rooms and project, task, and hourly tracking tools.

 

It is important to contain our enthusiasm however.  The incredible progress in these areas is not a guarantee for an easier dev process over-all, or a higher quality result, much less an end-to-end solution for development.  Inherent in this virtual development world are new risks and pressures placed upon your project manager.  You may save time but give up key controls.  A feature of your platform may rely on a module written by a unknown distant developer you have never met.  But it is most important to understand that any of these new tools and services still lack basic ingredients to your success.

 

The truth is that successful websites and mobile applications are still the result of imagination, ingenuity, elegant design, unique vision, solid product strategy, and effective marketing – none of which can be outsourced, downloaded, configured, or hosted.  You still need leadership, talent, and experience.  You need a team that works well together. You still need experts and gurus.  And of course you need a great project plan to pull it all together.

 

 

Make sure your project plan and tools are well organized and include the following

 

  1. Project Summary
  2. Project Goals
  3. Team Structure
  4. Activities
  5. Deliverables
  6. Dependencies
  7. Risks
  8. Communication Plan
  9. Tasks, Work Schedule, Milestones
  10. Testing Criteria
  11. Production Launch Criteria
  12. Is Web based or web enabled for multi user edit and access

 

Helpful Links

 

Project Management Software

Comparison of Project Management Software

Basecamp

Bugzilla

Follow logicaldesigndb on Twitter

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.

 

 

Google Insights For Search

How do you know what people are searching for by Region, City, or Country.   Google Insights for Search!   Watch this video for helpful information and 2 minute explanation.

 

 

10 Reasons Your Application Development Project Will Fail and How You Can Avoid Disaster

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!

Project Disaster

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.

Follow logicaldesigndb on Twitter

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

 

 

More Articles Like This: “Should You Trust Your Project Plan?





 

Want to download your own copy?

For a limited time, you may download a FREE version of this white paper.
Just sign up with your email on this form .  You will receive a download link after you confirm your email address.

 

How make a Facebook Landing Page

 

Google Webmaster Tools

Learn how to improve your site design to attract more visitors.  Google Webmaster Tools give you insight to how their crawlers work, how they view your pages, and how to make changes that will boost your ranking.

 

App Development (scrum) in About Eight Minutes

On time and on budget app development is unfortunately still as rare as penguin in the Sahara.  To lower risk of failure, techies have developed proven methods for structuring the work involved.  This video describes SCRUM methodology for application development.

 
  • Page 1 of 2
  • 1
  • 2
© 2011 Logical Design Database Solutions All Rights Reserved
Resources