The Critical Phases of a Software Project

The Critical Phases of a Software Project

Mention 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 – and sometimes the reputation is deserved.

During our 30 years in business, DragonPoint Software has worked to overcome that 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 to our successful software projects?

1. Clear requirements that define the work to be completed in a way that makes sense to the business and technical teams.
2. Creating a strong system architecture.
3. Experienced programmers with a proven track record of success.
4. Testing and re-testing to ensure the system works as expected.
5. Deploying the software using a repeatable and reliable process.
6. Training people who will use the software, focusing on the functionality of the system and how the application meets the company’s business requirements.
7. User Acceptance testing, which provides the people who will use the system with the opportunity to confirm it meets their needs.
8. Documentation, primarily on-page help, that explains how each feature works.
9. 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 and click on any of the links above to read more about the key to success.

Who does what in a successful software development project?

DragonPoint’s software development methodology includes these steps, each performed by the right team member(s) for the job.

Requirements

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, makes suggestions, and asks questions to clarify requirements. After meeting with the client, the PM or analyst numbers each requirement and writes the requirements document. Initially a mockup of every screen is included in the requirements, and later in the project, new screens may be mocked up or the document may reference another similar screen on which the new page will be based.

Weekly meetings with the PM and the client are used to continuously 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). Expecting programmers to translate verbal requirements from the client into code is a recipe for disaster! Failed systems result from incomplete, vague, and/or inaccurate requirements.

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 special 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 (screens) or database (where your information is stored), or they may be “full stack” developers, who code 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 is an important part of a project because it helps ensure that everyone working on the project is accessing the most current version of the code, and it 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: There are lots of reasons why the programming part of a project fails.

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 coding can sink a project include:

1. Ignoring written requirements (or coding without them)
2. Not following the system blueprint
3. Getting the project 90% complete but never making it to 100%.  Warning: if you keep hearing that your new software is 80-90% complete, you may need an intervention to get to 100%, because following the same process is not working.

Click here for two more articles to help you have a successful software project:

1. 1. Successful Software Projects – Setting The Foundation!
   2. Ensuring Success with Testing, Deployment, and User Acceptance – DragonPoint

Ready to take your software from concept to code? Contact DragonPoint to learn more.