Flash Platform from Start to Finish: Working Collaboratively Using Adobe® Creative Suite® 5 — High-Level Vision and Team Organization
Note: This excerpt is from a draft manuscript and may not be representative of the final published work.
From the book
From the book
From the book
How many times have you been in the middle of the design or development of your project and wanted to slap yourself on the head and ask, “Why didn’t we catch that already?” or “Why did we do it this way?”
Getting your Flash Platform project started on the right foot can be the most important part of ensuring a successful project. If you don’t take the time to define your project goals in the beginning, then unexpected issues may crop up later. In this chapter, you’ll learn the steps of successful high-level planning, how to define the boundaries of your project, how to get information about your end users, and how to set the stage for more detailed planning and feature definition for your design and development teams.
High-LevelVision
The beginning of any sized project should always start with defining the high-level vision—a brief synopsis of the project that defines the basic questions of who, what, how, why, and when. The high-level vision is the starting point for all planning, design, development, deployment, and maintenance phases of the project. It frames the project’s bounds, starts the process of asking important questions, and allows you and your team to start defining goals that will lead to a successful project. It is also a building block for the project, one that you can return to to verify that the project is on track and that it remains focused on its original goals.
If a client hires you or your team to develop a project, they may define the high-level vision for you, or defining the high-level may be your or your team’s responsibility. Even if the high-level vision is already defined by the time you join in the process, it’s important for you and everyone on the project to understand what a high-level vision is and why it can influence later phases of the process.
Who is the project targeting?
The first question that should be asked when defining a high-level vision is, “Who is this project for?” In other words, who is the client for the project? Is the client the end user, or does the client have its own set of users? Are you building an application for your company’s internal team or business management? Or, are you the target audience of the final application?
If you or your team is building an application for a client, does the client know who their user base is yet? If not, then this is the time to start defining who the intended audience will be.
If the project is for your company, then it’s critical to understand who exactly is going to use the final application because the intended users will become stakeholders later in the process.
If you are the end user, take a few minutes to write down why this is the right project for you. You may realize that the project benefits more people than you initially thought. For example, if you are creating a data visualization dashboard for your team, you may discover that other departments (or even other clients) may need the same application because they are experiencing the same issues you are.
Many of the choices that are made later—such as the user interface layout, feature sets, deployment, and technology needs—are driven by the people who will end up using the project’s deliverable. During this phase, it can be easy to assume that the intended audience is obvious, and it may be to you (or your client), but take the time to identify and write down the audience so that it is clearly defined up front. Later in the process, you can use user research (covered in more detail later in the chapter) to further define the project’s target users.
What is the business problem?
The next question to ask is, “What is the business problem that the project is trying to solve?” A business problem is an issue that needs to be resolved. We use the term business loosely here, because what is trying to be resolved doesn’t necessarily translate directly into a money or revenue source. A project always tries to solve one or more business problems; if not, then why should the time, money, and effort be spent on the project?
Even in projects that are not strictly business related, it’s still important to define the problem being solved. For example, you may want to develop a free game that will be hosted on a Web site, yet there is an objective: to entertain. In this case, the business problem you are trying to solve is that there are bored people and your game will entertain them.
How should the problem be solved?
Now that you’ve defined what the business problem is, it’s time to ask yourself (or the client), “How should the problem be solved, or how does the end user need to have the business problem solved?” You are not trying to define in detail how the problem should be solved at this point; the goal is to roughly sketch out what you (or the client) believe is the best way to solve them.
For example, if one of your business problems is that client orders are not being properly tracked, a possible solution is to build a custom tracking system using a Flash front end with a ColdFusion back end. From this starting point, you can define more business problems that arise from the current process and how you would like them solved via technology.
Coming up with proposed solutions to the problem is merely a starting point to inspire more thought and drive research to verify that the proposed solutions solve the defined business problem. Don’t worry about being too specific, if you try to lock down the specific solutions at this stage, you will likely have too many open issues and assumptions.
Why should it be solved this way?
With the proposed solutions outlined, it’s important to ask, “Why should the problems be solved this way?” Understanding why the proposed solution is the right one is just as important as understanding what the problem is. If the solution solves one problem but creates new issues, it’s not really the best solution.
During this process, you should also look at whether the competition is solving the same problem and, if so, how they are solving it. If they’re not solving it, then that is great validation to support why you need to solve the problem. If the competition is solving the issue, how can you improve on their solution? Has their solution created more problems than it has solved? If so, how can you use this information to your advantage in your project planning and development processes?
When should it be solved?
Knowing when the project has to be done is critical to defining the project process. So ask yourself, “When should the problem be solved?” Is this a quick-turnaround, small-budget affair? Is this project locked to a set delivery date to meet marketing or business needs? Is this a mission-critical system that has to be right no matter how long it takes?
As with everything in the high-level vision, you don’t need to have a set end date to complete the vision, but having a time range is important to structuring the overall process.
One thing to consider during this process is having too much time. Some of the most over-budget and problem-ridden projects have no time limit. Having some kind of timeframe for the project—even if it is an artificial deadline—can help structure a project and enable everyone to be in agreement as the project moves forward.