Itomic has been design and building websites since 2000… and some team members a little longer than that. But website projects still don’t always run smoothly – despite everyone’s best efforts and intentions.
Most of Itomic’s website projects run reasonably smoothly, but we’ve certainly had our share of challenges over the years. And we’ve learnt from them. We’re pleased to share with you a list of what we believe to be the Top 10 Website Project Risk Factors… and how to mitigate against them.
Too many decision makers (stakeholders, committees)
This can cause bottlenecks in the decision and approval process. Ensure that project managers/representatives are sufficiently empowered and supported to make decisions.
Custom-coding to get features “just right”
Sometimes compromise is necessary. Sometimes 90% of a feature is good enough if delivering on that last 10% is going to take 100s of hours of custom coding and testing and cause large time and budget overruns. KISS!
Ensure that project communications and status reporting are clear, up-to-date and accessible to new project members.
Both client and supplier must be on the lookout for the dreaded scope creep. Scope creep is where new project features are being requested that didn’t form part of the original brief, and can’t have reasonably been expected to be included. Additional feature requests must be evaluated in terms of likely project impact, and decisions then need to be made in terms of whether to include or not include the new feature requests in the current phase.
Underestimation of the time/resource commitment
On average, we observe that clients underestimate the amount of time they themselves will need to invest in the project for it to keep on moving forwards promptly. After all, many clients are already doing a full-time job, and the website project is in addition to that. All project members need to be granted sufficient time alongside their normal duties.
Misunderstandings about what a “normal” project entails
Perhaps the most typical misunderstanding is that “bugs” (or “issues” as we prefer to call them!) are not a normal part of the development lifecycle. The reality is that they are, especially when you’re dealing with complex systems, millions of lines of code, and custom requirements. The purpose of the testing phase is for the client to work with us to identify and resolve outstanding issues – of which there may well be many on a large, sophisticated project. Fyi there’s almost no such thing as a bug-free software project.
Inaccurate project estimating by Itomic
Estimating the time it takes to develop software development is notoriously challenging. It’s not an exact science, even armed with highly detailed functional and/or technical specifications. Although we use tried and tested techniques, they remain “estimates only”. Regular project updates ensure that the client is kept informed in the event that estimates and actuals are diverging significantly.
3rd Party Systems (integration with)
Integrating (synchronising, importing/exporting) a new system with one or more 3rd party systems can seem straightforward on the surface, but can sometimes prove very challenging. If such integration is mission-critical for overall project success, then the requirements must be fully identified and tested/prototyped, and sooner rather than later.
Data migration / population
Similar to the above, time and effort is typically underestimated to source the content, and to populate the new site with that content. It’s important to fully identify and specify all data (i.e. website content) that is to be supplied for the new site, whether it exists yet, who has it, what format it’s in, etc.
It’s harder than you think to get websites to look and function perfectly on every version of every browser (old and new) on every screen size and orientation (portrait or landscape). The combinations are almost infinite. Optimising for a specific combination can cause de-optimisation for another. Try to ensure that your websites are standards-compliant, but still accept that perfect consistency is virtually impossible.