This chapter is from the book
This chapter is from the book
This chapter is from the book
Understand the Project Approach
Knowing the overall approach, or methodology, of a project is an important part of understanding when and how you'll be involved and how you should be involving others, such as your project team and business stakeholders.
Sometimes there seem to be as many project approaches as there are projects. How to choose the right approach for a project is a large topic in itself. The methodology you choose can depend on many things, including the structure and location of the project team, the technologies being used on the project, and the degree to which collaboration is a part of the company's culture. For the purposes of this book, we're assuming that you've joined a project where the approach has largely been determined by those responsible for the project's success, such as the project sponsor and project manager. In this situation, your main goal will be to understand the approach and help make it effective for the business stakeholders and your users.
Here we'll focus on two of the most common types of approach, as well as a third that shows a possible variation you might encounter on a project. The important thing to note is that most approaches involve the same steps:
- Plan the overall strategy, approach, and team structure.
- Define the project requirements.
- Design interaction and visual concepts and evolve them into detailed specifications.
- Develop, test, and refine the solution.
- Deploy the solution via messaging, training, and a planned launch.
- Extend the project by making recommendations for improvements.
The names for these steps may vary, as may the degree to which they overlap and the way information is documented. But the general activities in each step are common to most projects and to all three models presented here.
Waterfall Approach
A waterfall approach involves treating the steps of a project as separate, distinct phases, where approval of one phase is needed before the next phase begins. For example, the Design phase does not begin in earnest until requirements have been approved by business stakeholders, who sign off on one or more requirements documents at the end of the Define phase.
)
Figure 4.3 Example of a waterfall approach, where each phase "falls" into the next
The problem with a pure waterfall approach is that it assumes that each phase can be completed with minimal changes to the phase before it. So if you come up with new requirements in the Design phase, which is common, you must suggest changes to documents that were approved at the end of the Define phase, which can throw off the plan and the schedule.
Agile Approaches
Because change is constant, project teams are continually looking for more flexible approaches than the waterfall model. Many methodologies follow a more fluid approach, with some steps happening alongside each other; for example, versions of the Web site could be released on a rapid, iterative schedule using an agile or rapid development approach. An agile approach generally has a greater focus on rapid collaboration and a reduced focus on detailed documentation and formal sign-off.
)
Figure 4.4 Example of an agile approach
A true agile approach (following the best practices developed by members of the Agile Alliance, for example) calls for small teams whose members are located next to each other physically, with little focus on defining formal roles between team members. Working this way allows a very high degree of collaboration, which reduces the need for heavy documentation between the stages of design, development, and testing. A team member can pose a question, come to the answer together with other team members during a quick whiteboarding session, and implement a solution without the delay of detailed documentation and approval. Stakeholder reviews occur with a fully functioning system when one of the many iterations is released, and the resulting input is taken into account as the next iteration is planned. (Iterations are draft versions of a particular site or application.)
When an agile approach is working as it's designed to, it's a beautiful thing. At most companies and within most consulting engagements, however, teams rarely follow a pure agile approach. In part, this is because companies are increasingly using distributed teams and remote workers, which makes it difficult to maintain the high degree of collaboration needed to take best advantage of the pure agile approach.
Modified Approaches
Most projects try to follow an approach that marries the best of both worlds, with enough structure and documentation to reduce the risks posed by distributed teams and turnover of team members, but enough collaboration and iteration to respond to changes in a relatively nimble way. For example, a project may follow a waterfall model but include an overlap in phases so that there are key collaboration points from team to team. This allows potential changes to surface earlier in each phase. This may also include an early release (such as a beta release to a particular user group) with a shorter iteration cycle. Feedback from that release can then be incorporated before the full deployment of the new site.
Notice the smaller iterations within the Design phase in the Figure 4.5. That's one of the greatest values you bring to your team as a UX designer. Tools such as wireframes (Chapter 11) and prototypes (Chapter 12) allow you to gather feedback on quick iterations of ideas, before a lot of development time has been put in.
)
Figure 4.5 Modified waterfall with beta release
A modified waterfall approach like the one in Figure 4.5 is among the most commonly used methodologies, so it's the approach that forms the framework of this book. However, many of the topics covered here will apply to your project regardless of the specifics of your approach, because the basic activities behind them—defining and designing, for example—are still necessary.
Deep Diving
If your project is using an agile approach, you'll have unique needs during requirements gathering, such as the writing of "user stories" as a way to capture requirements. We recommend User Stories Applied: For Agile Software Development by Mike Cohn (Addison-Wesley Professional, 2004).
How Does the Approach Affect Me?
Knowing your approach helps you understand a number of things:
- What questions you should be asking, and when. For example, if you're working with a pure waterfall approach, you'll need to put in extra effort to make sure the requirements captured in the Define phase contain all the information you need for the Design phase. (We'll be discussing requirements in the next chapter.)
- Expectations on how project team members will collaborate and how close that collaboration will be. For example, an agile approach requires very close collaboration. A waterfall approach may involve individual work most of the time, with touchpoints once or several times per week.
- The level of detail needed in your documentation and the level of formality. Documents submitted at sign-off points need to be formal, almost like legal contracts. Typically, you'll need more formal documents in a waterfall approach, where sign-off is required before you move on to the next phase. However, you may also have some formal sign-off documents when using an agile approach—for example, to capture information at major decision points, such as when a particular iteration is prepared for full release and deployment.
- Important milestones that involve approval from stakeholders and deployment to different groups. The approach will determine what different audiences need to provide at various points in the project, including approvals from stakeholders at sign-off points and feedback from potential users during a beta release.
Now that you've solidified your project objectives and gained an understanding of the project approach, in the next chapter we'll start with the primary work in the Define phase: gathering requirements.