Mention custom software projects and lots of people cringe. Why? Software projects have a bad reputation for being over budget, notoriously late, and a huge disruption to your business. Sadly, some projects deserve the bad rep.
During our 30 years in business, DragonPoint Software has worked to overcome the industry’s bad reputation by creating a repeatable process for successful software projects. Our projects start with a great team that has worked together for years. What are the other keys?
- Clear requirements that define the work to be completed in a way that makes sense to the business and technical teams.
- Creating a strong system architecture.
- Experienced programmers with a proven track record of success.
- Testing and re-testing to ensure the system works as expected.
- Deploying the software using a repeatable and reliable process.
- Training people who will use the software, focusing on the functionality of the system and how the application meets the company’s business requirements.
- User Acceptance testing, which provides the people who will use the system with the opportunity to confirm it meets their needs.
- On-page help that explains how each feature works.
- Go live and ongoing support and enhancements of the system.
Click here for more information on how structuring your software development team can support project success.
Requirements for Custom Software
Before coding, define the requirements in writing and with pictures that show you what system pages will look like.
Who: Requirements Analyst and/or Project Manager (PM) working with the client PM and subject matter experts
How: The business analyst or project manager meets with the client and listens and asks questions to clarify requirements. After meeting with the client, the PM or analyst numbers each requirement and writes the requirements document. Initially the requirements include a mockup of every screen, and later in the project, requirements may reference a similar screen instead of including a mockup for every page.
The PM and the client meet weekly to review progress to date, refine existing requirements and identify new ones, and discuss next steps. The PM keeps the client informed about the status of the budget and identifies out of scope tasks that require client approvals (and potentially, additional time and funding).
Failed projects: Verbal requirements are just suggestions that nobody can test against or measure as complete (or not). Don’t expect programmers to translate verbal requirements from the client into code. Incomplete, vague, and/or inaccurate requirements produce failed systems.
Architecture
Similar to the way a construction architect develops blueprints for a building, a system architect designs the blueprint for the application.
Who: System Architects
How: The architect translates requirements into a technical blueprint for the system.
Failed projects: System architects have a non-standard toolset; programmers who generally write reports or follow existing code patterns may be destined for failure when thrust into the role of a system architect.
Programming: Write the software.
Who: Programmers
How: Programmers use the tools and framework defined by the system architects and follow standards defined for the project to code the screens and functions described in the requirements document.
Programmers may specialize in one aspect of the application (sometimes called a layer of the system), such as the User Interface/User Experience (screens) or database (where your information is stored), or they may be “full stack” developers. Full stack means one person codes all aspects of a page or function, including getting the data for a page, coding the page and its business rules, and saving the data entered/updated on the page. Both approaches can be successful based on the skillset of the development team.
After programmers finish coding a unit of work, they test it and check it into source control, which helps ensure that everyone working on the project is accessing the most current version of the code. Source control also avoids overwriting work completed by one person with someone else’s code.
On a regular basis, programmers meet with the project manager to clarify requirements, report progress, and plan next steps.
Failed projects: not using a source control system; asking the wrong developer to write the code (for example, having a database specialist write UI pages); missing or ignored requirements.
How to Sink a Custom Software Project
DragonPoint once took over support for a software project (after the sole developer died), and figuring out which version of the code to use was a nightmare because there were so many versions of the application, source control was not used, and it was very difficult to identify the production version of the code.
Other ways to sink a custom software project include:
- Ignoring written requirements or coding without them.
- Not following the system architecture / blueprint.
- Getting the project 90% complete but never making it to 100%. Warning: if you keep hearing that your new software is 80-90% complete, it’s time for an intervention! If your project is stuck at 90%, change processes to get to 100%.
What Happens at the End of a Custom Software Project?
After your custom software system is complete, tested, and moved into production, support begins. DragonPoint’s first priority is keeping production systems operational. Our goal is to work ourselves out of a job by ensuring you have a great custom software system that fully meets your business needs!
More Information
Click here for two more articles to help you have a successful software project:
Ready to take your software from concept to code? Contact DragonPoint to learn more.
