I recently sat down to read the May edition of Harvard Business Review. The cover article for the May edition, written by Proctor&Gamble‘s CEO A.G. Lafley, is titled “What only the CEO can do.” In the article A.G.Lafley discusses the main tasks of a CEO. The second of those tasks is what I was quite interested in, as in another form it is quite pertinent for designers. The second task A.G Lafley describes in the article is Deciding What Business You Are In.
The Design version of Deciding What Business You Are In is deciding on the scope of the design project.
Deciding on what will and what won’t be within the scope of a design project is an important skills for designers to develop. If you really nail the scope of a project at the correct time, you are more likely to deliver a project that is on time, within budget and will make your client extremely happy by providing an excellent product. If you don’t nail down the scope of the project you will be floundering all over the place and the project could become an unmitigated disaster.
What is Scope?
Scope is defined by dictionary.com as “The area covered by a given activity or subject.”, at its core Scope is about making a clear definition not only about what you will cover in the project, but also just as importantly, what you will not cover in the particular project.
Clearly defining these two things is crucial as it allows you to focus the various aspects of the project (such as research and design) so that you don’t end up way off on tangents that are completely unrelated to the project (This is not to say that tangents in design projects can’t be productive). This is particularly important in long projects. In long projects extensive scoping should be done in conjunction with extensive project planning. Scoping forms a major component of many project planning methodologies. For younger designs, especially those still completing their design degrees, learning to scope a project is an important skill.
Remember when you are a design professional, unless you are using your own money to financially back your own products, you will be funded by someone elses money – whether a clients or that of the company of which you are an employee, either way they will want a return on investment and don’t want you to burn money for no good reason.
Scope vs. Brief
Is there a difference? Many people might argue there isn’t. However it is my view the Scope and A Brief are two separate, yet related documents.
A brief is a document that I would expect to receive from a client that gives a broad overview of the project and what they currently perceive as the outcomes of the project. While the Scope defines specific stages of the project that will lead to a final outcome. It will define what is important in the project and what is not. It will also help define how much the project will cost. A scope can help place constraints on the project, which in turn will help you come up with a more creative outcome that truly addresses the design problem.
Scoping A Design Project
Now that we know a bit more about scoping, the question is how do you go about it?
1. Start with the clients brief. Important details to take away from the brief include -What is their envisioned outcome for the project? Do they have budget? If so can you achieve the envisioned outcome and meet the budget? (If a project is well scoped, it can often be used to explain to a client why their budget might need to be expanded for the project).
2. From this, map out an overview of the steps, from start to finish, that you will need to take to achieve the project outcome. The most basic scope would include – Planning, Research, Initial Design & Development, Design Refinement and Documentation. Bare in mind that all the activities in the scope are not necessarily completely separate tasks. Design being what it is they are more often than not, interrelated and you may revisit activities at various stages of the project.
3. Detail and describe each section. eg: Research might include literature reviews & general information gathering, surveys, talking with customer/potential users (interviews), photographic documentation, current and future trend analysis and gap analysis. The sub-sections will also need detailing and describing.
4. The completed Scope can now be utilised to perform costing, more extensive project planning and project tracking, as well as a range of other functions.
When should I complete the scoping?
The time at which you create the project scope is also of critical importance. Many design projects are particularly fuzzy at the front end and throughout various stages. And so they should be, to gain real insight into peoples lives or into a particular problem it needs to be so. But there comes a point where you need to start giving the project definition and scope or else you might spend the entire project in the fuzzy and end up on an unrelated and non-useful tangents or run out of time.
I personally believe that the best time to scope a project is: 1. for personal projects – once you have a few basic ideas jotted down in your notebook (based on insights you have gained) 2. when a client provides you with a brief. Remember to continually update the project scope as you feel necessary. Parts of it will become a living document. A Scope should never be completed and then just left in a draw or fall to the bottom of all those papers on your desk.
Document
The importance of scoping a project becomes clear when you end up in a dispute with a client over what has or has not been done in the project. Or when you start missing important deadlines. For student/university projects a Scope will keep you on track so you don’t miss those deadlines.
If the project brief and project scope are clearly defined and/or well documented through out the project (they will most likely change over the course of the project) then you can easily work through disputes. However if not, since you are using the clients money, you may have a hard time resolving any disputes quickly and effectively. Many un-scoped projects will run over budget and end with the designer not being paid or in some kind of legal battle over what was or wasn’t done.
The one constant in life is change. And it is a constant that applies to all design projects. The client is almost always guaranteed to change thier mind about something. If the project is properly scoped and you update and document changes over the course of the project, you can utilise the scope to manage client expectations, track the project and also make sure you are remunerated accordingly.
A very interesting article, but I would personally consider most of what you talk about as being a project plan or proposal. That is not to say what you have written isn’t valid or useful – I will be recommending it to anyone in need of guidance of running projects, but it applies to their design plans, not the scope.
As you mention, scope refers to the area covered by a project – that is, the length and breadth of the subject, and not the detail. It defines how far from the core idea the design activity will explore, how wide the research and influences will look, and how far-reaching the outcome will be. Will it be limited by a particular market? Does it need to perform a particular function? Can it be used in different ways? Should it cater to the needs of X? These are the questions that uncover the scope of a project, which in turn informs the creation of the project plan.
As an example, and for the benefit of anyone just starting out, when I write a project proposal for a new client following their briefing, I create a document that consists of the following:
Situation Summary – a brief breakdown of the client’s current overall situation. This is the first stage of defining the scope, and positions the project within the activity of the client’s company as a whole, and their intended direction for it.
Project Outline – an overview of the requirements of the project, based on the client’s brief and your understanding of their problem, and how you intend to resolve it. This is where the scope of the project is defined in its entirety, specifying what each stage should accomplish. However, this is still seen as an overview without specific details of each design activity, as it defines the benchmark against which the success (or failure) of the tasks defined in the next sections are judged.
Module Outlines – these break the project into its main stages, and within each details the key activities that will take place. Already having the scope defined in the Situation Summary and Project Outline makes writing this much easier, and allows you to easily plan the tasks required to resolve the client’s brief without veering away from the original scope for the project.
Sorry if that’s teaching anyone to suck eggs, but I find its often useful to see how others approach a similar problem. I couldn’t defend it as being the best method… but its my method! And I hope its helpful to someone?
Martin,
Thanks for stopping by and taking the time to truly add to what I have written by sharing, in detail, your methodology for project planning. I think what I have talked about and what you have talked about are essentially a similar thing. At their core each one is a methodology for achieving an aim. The aim – providing clarity to people working on a particular project. I think the main difference between what we have both described is more on the level of the language have used to describe it. Your description of scope is also much more refined, robust and clearly worded than mine.
Again thank you for taking the time to make an in depth response.