So, you have just been handed a major enterprise-level web development project? Congratulations! While you finish sipping your glass of champagne, let's review a few things that will assure your project is successful.
Here are the six principles we followed when working on a 12 month web development project for a large pharmaceutical company.
If you are working on a sizable project that starts with 200-300 requirements, chances are you will be juggling 1,000+ requirements towards the end of the project. If you don't have a methodology and system to manage those requirements, you will soon drown in a sea of specifications. At Six Feet Up, all of our projects are managed through Trac, a nimble open source project management tool. We use a dedicated and customized Trac instance to manage each project's requirements. In the case of a recent large project we did for a pharmaceutical company, each requirement was captured in a ticket and was assigned primary and secondary functional areas. This allowed for quick browsing in case a search returned too many results (we are approaching 3,000 tickets as it is, so this tends to happen). We also captured the requirements using Trac's wiki and used them as a legend on the wireframes.
As a project manager faced with a heap of tasks to assign, your natural instinct is automatically to being breaking everything down in manageable categories of work. Authentication work goes there, custom types over there, templating work here and reporting tasks way down the road over there (or did it fall behind the heavy-duty cabinet in the Accounting Department?) Now, that feels better. That is, until 6 months later when the dreadful reporting specifications rear their ugly dusty head from behind the cabinet and demand some core changes in the system... That's when developers shake their heads in disbelief, project stakeholders demand another Gantt chart update, and you look like a deer in headlights.
But this does not have to be so. Prior to writing the first line of code, make sure to thoroughly consider all major components of your projects, especially the ones related to analytics and reporting. It is much easier to design a system with the reporting specs in mind than adding analytics to a finished solution.
Oh boy! Now the reality of that huge project is settling in and you have been asked to provide a "traceability matrix". Do not fret! This is actually going to be your best friend, especially in the long run. The traceability matrix connects the business requirements to the technical requirements, the technical requirements to the task tickets, the task tickets to the test tickets, and the test tickets to the issue tickets.
We used Trac to build our traceability matrix and this, combined with custom canned queries, gave us a solid understanding of where we were at all times during the development process.
Beat this into your project managers' heads so they can beat it into their developers' heads: document and update your documentation regularly. If you fail to keep your specs up-to-date, it will be really hard to bring new developers or quality analysts onto the project. Worse, your team will not remember how something is supposed to work once you have customized the functionality a few times based on end-users' feedback. This will result in false alarms raised by your testers, as they tend to be the last people who are notified of a spec change. And handling false issues can become expensive really fast.
At Six Feet Up, we update both the project wireframes, the wiki-based specifications and the tickets (and all three point to one another) to ensure we all know what the system is supposed to do.
The party is over and all that is left is you and this brand-new BIG project that looks like it will suck all your resources, and some. But if you add resources external to your core group of developers, how do you ensure the level of quality you pride yourself on providing? How do you make sure Jim does not break what Jane just committed? Catching this at the testing phase is too late, as it will necessitate developers researching what caused the issue before they even investigate how to fix it.
Instead, be sure to implement a continuous integration process, whereby developers changes are subjected to some automated tests after they commit. While this is not 100% bug proof, it is likely to catch many of the problems very early, and save you much trouble down the road. At Six Feet Up, we use a software called Hudson to automatically run tests each time code is committed. If something breaks, we get notified by email within minutes and can then address the problem right away by either rolling code back or fixing the issue.
As in any large project, you are likely working with a large team of interested parties and stakeholders who all have a slightly different understanding of what will come out of this project. How do you keep everyone in the loop and happy?
Just ask my 5 year old: pizza parties and "show and tell". OK, you may skip the pizza, but do plan on having regular "show and tell" sessions where you demonstrate how the software works and give your colleagues an opportunity to ask questions. Involve some of your developers so that they get some immediate feedback as well. We recommend at least one "show and tell" meeting every two weeks for a large project. At the beginning of the project when programming has not started yet, be sure to go over the wireframes with the extended project team. Scheduling those sessions early on will give you buy-in and credibility, and will shield you from last minute requirements.
Sticking to these principles has allowed us to catch and address potential issues early, and therefore meet both our time and budget requirements. Have you identified other critical rules for a successful enterprise-level web project? Please share them here!
Six Feet Up, Inc.
11208 Windermere Blvd.
Fishers, IN 46037 - USA
Phone: +1 (317) 861-5948
Email: info@sixfeetup.com
