Nervous About a Large Software Project?
Large projects make us nervous for good reason. Software projects implode on a regular basis. Why should yours be any different? How can you avoid becoming a statistic? Our recommendation is pretty obvious -- run your project differently than the failures.
This isn’t about cleverness. It’s about process. We only slightly exaggerate when we say that, in software, the process is the product. Good process – good product. Bad process – bad product. Here’s the problem: If you’re not a software industry insider, you don’t understand what a good process looks like. And why should you? You already have a job and it’s not running a software company. This is really no different from the problem we all face when hiring a professional outside our expertise, whether it’s an attorney or a septic tank installer. We have to trust someone. The question is who?
Here are some attributes to look for as you select an automation planner.
Objective – Do they have a one-size-fits-all product to sell?
Accessible – Can you reach them by phone, email, IM and text? Do they reply quickly?
Proactive – Do they seem to have your success on their mind from day one?
Experienced - Your project is too important to be somebody's learning curve.
Trustworthy – Cut through the malarkey and ask the reference question that matters: Would you hire this firm again? Why or why not?
As for process, we’ve put together a short list of ten questions that will help you know if you are ready to proceed with your project. It will also give you an idea how to go about preparing for it. Download our Ten Questions for Automation Readiness.
Building Custom Software
Don't get the wrong idea -- custom software can be fantastic. It fits like a glove, taking into account the nuances of your business model, market segment, and employee culture. Once you decide to build a complex software application, however, a number of challenges arise:
- What business objectives must the system meet? This is the "Why?" level of questioning. These objectives drive the rest of the process. Skipping this step causes projects to "hang" when conflict arises between staff members over specific features, or budgets are needed that require cross-division cooperation.
- Who will the system serve? Everyone can see the low-hanging fruit on this one. But what about back-office functions? Layers of customers with different privileges? Management hierarchy? Missing an important audience undermines your security model and causes missing features that must be added later at greatly increased cost.
- What must the system do? A few pages of bullets will not do here. Features must be elicited for each relevant audience, clarified, prioritized and divided into phases of development so that everyone -- business sponsor, designer, developer, tester, installer, trainer -- knows what is expected during the project.
There's much more to a software blueprint than these topics but you get the point -- defining a software system with enough clarity to succeed is a substantial task.
Don't leave the critical process of requirements gathering to the optimistic sales force or the busy developers. Learn how our Dynamic BlueprintTM process can save you time, money, and aggravation -- improving the odds that your project will succeed.
