This post will be quite listy as it is simply a description of the roles you need in place to build a successful software product. These are roles, not titles. There are no rules that state you cannot have one person doing multiple roles. If you’re a one man/woman development shop, you’ll find yourself a lot like the new Staples commercial here. I’ll try to list them in the order they would typically appear in the process. Some will have just a small role in one part of the process, while others will span the entire process. Please note that my short blurbs are very high level and will likely not be representative of all the duties of that particular role.
- Stakeholder/Customer/Client – This is the person or entity that is requesting the software. They would be involved in the initial concept idea and provide funding for the project. They would also be involved after the completion of major phases of the project, such as analysis, design, development, and quality assurance, to provide feedback that the software is meeting requirements.
- Project Manager – This role maintains the timeline for the project and ensures that the correct resources are available when they need to be. They ensure that the project meets timeline, budget, and quality standards. The project manager is the most critical person in the project because they will need to be involved in all phases from initial concepting through to deployment or delivery.
- Business Analyst – This role creates requirements for the software. They are responsible for taking information from the stakeholder and translating it into specifications that developers can use to build the system. Ideally, the requirements documentation would be another touch point for the stakeholder to determine whether or not they are going to get what they asked for. After stakeholder sign off, these specifications are used by the quality assurance team to ensure that the delivered product meets requirements.
- UX Designer/Information Architect – This role creates and maintains the wireframes for the product. They take the specifications and translate them into something graphical that the designers can begin to work with. They capture each of the requirements provided by the business analyst and lay the initial plans for the functioning piece of software.
- Designer – This role creates the design of the software product, combining efforts from both the Business Analyst and the UX Designer. The deliverable is graphical files from which the developers can begin their work. After the designer completes their work, this would be another point for the stakeholder to approve continuing to move forward. Additionally, this role may be involved in creating graphical assets from their design work that will be used in development.
- Art Director – This role monitors the work of the designer to ensure that it not only meets modern design standards and is aesthetically pleasing, but also that it conveys the tone or message of the stakeholders properly.
- System Architect – This role is made up of a few parts. The first one is to ensure that the necessary systems and resources to complete the technical part of the project are available. This includes servers, source control, development machines, developers, etc. The second is to estimate the development effort of what has been provided by the prior roles. They need to take into account design, user experience, and requirements. They architect the development and provide a UML diagram to the developers. Lastly, they monitor development to ensure it is meeting expectations.
- Developer – This role takes the UML diagram from the architect as well as the design from the designers and builds the actual product under the direction of the architect. Because development is generally the longest phase of the process, progress meetings should be set up at regular intervals. The developer should be self-testing their code to ensure that it meets business requirements set forth by the business analyst.
- QA Analyst – This role tests the work completed by the developers to ensure it meets the designer, business analyst, and functional specifications. They are the last line of defense before delivery. It is important that the time necessary to complete this step makes its way into the overall project plan.
The one other role I considered, but did not add, is that of a technical lead. Depending on your organization, you may need a person between the project manager and the technical team to ensure both groups are on the same page during the entire process. This role could be filled by the architect, but you may break it out separately as well.
So there it is. Some projects may use everybody in the order listed, but the reality is that the majority of the time, software development is an iterative process. Stakeholders may not know that they don’t want what they said they wanted until the see it in front of them. It’s very important to keep them in the loop.
It’s also important to do your iterations at the point where it’s easiest. This means that you may need to go through your requirements or wireframes a couple of times. It’s easier at that time then during the design phase. It’s easier to change a design than a full-blown application.
Lastly, your project will be most successful if you don’t skip any of these roles or their deliverables. Many organizations have a tendency to skip one or more to save time, and it ends up costing more time and money at the end. Following all the steps gives you the opportunity to make changes when there is the least effort involved. However, you may alter the fidelity of your effort at each of these steps as your project needs dictate.