I started preparing this document at my last company where I worked as Head Technical Consultant. We had a small team of developers and a few Technical Project Managers that were responsible for the delivery of the scopes. I produced this as a starter guide for things to remember when meeting with new clients so that the entire project process could run a little smoother.
While I’m not the most technical person, I know more than the average client and have a good base understanding of technical elements…. enough to know that I don’t know enough.
When reading you can swap “Surf the Dream” for your own company, and “Head of Projects”, “General Manager” etc etc, with the appropriate heads of business. If you’re like me, it’s now a one man show so you’ll be wearing lots of different hats. You will also see that at the time of writing I was heavily involved with a gambling client.
When you’re getting started, remember these first few things…
- Take the client through what they should be expecting at the end
- Get them to do some preparation work that you can work from. It’s always better to take a partly completed scope to the client to see how the document they will be receiving is laid out so they know what input they need to provide to you.
- Explain that scoping is a long, but very worthwhile, process. Try and get people to start the scoping between 9.30 and 11.00 and work through to a late lunch at 13:00/13:30. Scoping after lunch means people are less focussed. If you’re running a full day of scoping then it’s probably best to have a short session straight after lunch to talk about some cool new things on the their areas of interest (html5, css3, ipad applications) or demo some of your previous project work to get everyone interested again.
Project Goal
The Project Goal usually takes the shape of a sentence, sometimes a short paragraph, that give the general business reasons for the project and will describe exactly why the client is spending money on this project.
It is from this paragraph that you will be able to extract the detail of the deliverables and create more of the “how do we go about reaching the goal”.
An example would be….
- “Become the #1 online only gambling site in Europe”
- “Increase revenue by 30% through moving the customer focus from Print to Web over the next 3 years”
- “Increase revenue by 15% through having the best interactive video website community for online debates”
If the client provides a Project Goal larger then a few lines, even if this is a ¬£100k+ project, you should work with them in reducing this so it’s to a point that the Project Sponsor can easily understand.
Project Objectives
I am sure you have noted that the plural, “Objectives”, has been used for this section.
The client is not going to be looking for just one deliverable for this project, that’s the Project Goal. It is important, as the person responsible for writing the scope, to ensure that these deliverables are detailed at a measurable level, even if the client wants to keep the a sounds fuzzy.
The Project Objectives are what will deliver the Project Goal, and is often what the Project Sponsor will use to gauge the success or failure of the Project. Rather then use these directly you might also round off the session with a list of items called “Success Criteria”.
You may find that some of the Project Objectives will form a scope item, but more often the not there will be several Project Deliverables for each of the Project Objectives.
Some Project Objectives may include…..
- “Provide a suite of products including Sports Book, Casino, Live Casino and Poker through a single sign on”
- “Deliver a Sports Book betting experience equivilant of Paddy Power and William Hill”
- “Increase online registration for exhibitions by 30%”
- “Increase web delivered articles from editors by 25%”
- “Create an online community of 50k users in the first year”
- “Increase revenue by 20% for premium content 1 year after launch”
Project Deliverables
The Project Deliverables is where you will put the majority of the detail for the Project Scope, and the most important thing is to avoid any ambiguity.
There should be 4 sections (generally) for each of the Project Deliverables, In Scope, Out of Scope, Assumptions, and Explanation. If you are working on the scope without the client, or time is short and you can not come to an agreement with the client, you can include another section called “Unresolved” to capture any tasks that haven’t fit into the In or Out section.
During the hand over meeting between Sales and the Projects Team you should start jotting down the areas that you know will be required for the project. Generally projects will already have quite a few similar Project Deliverables so it’s always beneficial to ask if someone has more information on areas that you are having trouble with.
Moving forward, we will create sections of Scope items for each of the “Out of the Box” product deliverables and regular deliverable items.
You should not worry if some Project Deliverables are short on tasks/content. For example you wouldn’t require too much detail for the purchase & installation of servers and configuration of Matrix if it is an existing client creating an Intranet on the same Matrix System, however you *would* include a task to ensure Matrix Feed is installed on the server if you were planning to include Imports as part of the project.
When adding individual tasks to the Scope remember that the Out of Scope items are just as important as the In Scope items.
Sometimes the Scope, depending on the size of the project, will not include wireframes or process flows so it is important to provide the client with an accurate description of not only what they are going to be receiving, but what they’re not.
The Out of Scope section can also be a good tool to include items that come up during the initial discussions with certain members of the project team that explain what they would like from the project in terms of “Amazon does….” “Google’s Calendar has…” “Facebook connects through….” and “BBC allows users to…..”
Of course, if the project is £100k+ then these can be reviewed a little closer.
It’s important that you do not use the Out of Scope area to exclude things that are in the project but not the responsibility of our Project team. This could lead the client to believe that it’s still being delivered as part of the project, just not by us.
Instead, next to each of the items/tasks against the Project Deliverables you should list the responsible party. If the task requires input from both the Project team and the Client, try and split the task to separate the tasks, and if that is not possible *bold* the party that you agree is overly responsible for that task (this should usually default to your agency).
Although it is the overall responsibility of the Project Manager, every Project Deliverable should have a responsible person assigned to that task, whether Internal, from the client team or a 3rd Party Vendor. This creates ownership and responsibility to the project team for every task.
If you’ve used the “Unresolved” section then it is usually because no one at the meeting can make a decision. These items should be referred to the Head of Projects or Sales internally, and to the Project Sponsor on the client side for resolution. If there is still a conflict between the In/Out decision this is where the Project Sponsor and Surf the Dream Senior Management will resolve the issue..
The Assumptions section is used to paint a better picture of the In and Out of scope section for the Project Deliverable. For example one of the deliverables might be “Surf the Dream to display 3rd party data records on homepage widget”. The Tasks might be for the
- 3rd Party to supply a access to the information through SOAP interface (3rd Party)
- Use API asset to retrieve XML or JSON (Surf the Dream)
- Display the items through server side javascript based on the design (Surf the Dream)
Now you might notice that a few things are missing here including how often should this be updated, can it be cached, is the item behind a firewall, what happens when the feed is unavailable etc etc. In the assumptions section we could include, “Surf the Dream assume that the 3rd Party has a documented SOAP interface with their product capable of serving valid xml/json with no security on access to this data. In the event that no data is available a simple ‘currently there is no feed’ is displayed.” While we would probably include the “No Feed” scenario in the Scope this assumption provides the client understanding that IF the 3rd Party does not have a documented SOAP interface etc etc then it is out of scope/will take longer/will cost more.
If between the In and Out and the Assumptions there still is some ambiguity it should be spelled out in the explanation section.
Identify the Project Sponsor
This is the person that can at any time stop the project in it’s tracks, and it is likely that they will not be attending the meeting you have booked. You need a Project Sponsor as part of any project as they are the ones who approve the payments and will allow the sign off of the project. The Project Sponsor will be the point of contact for either the Head of Projects, General Manager, or the Managing Director if at any stage of the project things are not going to plan.
Even though things are going to plan, it’s not always due to things caused by the Projects team. There could be a change of requirements that you believe will delay the delivery or increase the cost of the project, there could be issues with a 3rd party supplier beyond the clients or project teams control, and in a worse case scenario there could be a working relationship issue between the client and project teams.
What ever the issue, having the Project Sponsor involved at the very beginning allows the project teams to pass the difficult conversations on to senior members and just focus on delivering the project.
Project Cost Number of Sponsors £15k -£30k 1 £30 - £50 1 £50 - £100 1 £100+ 1
Identify the Project Stakeholders
These are the people that are going to be working with you throughout the entire project. It is best to catch up with the Project stakeholders individually to run you through what they think the project is going to deliver. Projects that have 3 or less stakeholders can be done as a group because
- It’s less likely someone will control the meeting and override others comments, and
- you will not have the time/budget to conduct individual sessions.
Each Project Stakeholder will be responsible for a particular section of the project you are working on. You will often find that one of the Project Stakeholders take on the role of the Project Sponsor for most of the project because the Sponsor has more than this project to worry about. While they are assuming this role you should get buy in from the Sponsor exactly what this particular Stakeholder can or can not sign off on. Depending on the Sponsors management style and IT knowledge, they will give them one of three levels of management
- Complete free reign over the project
- Free reign over changing the scope providing no budget/delivery dates are affected
- Ability only to sign off on scope that is agreed.
Obviously not all stakeholders needed to have individual sessions. For instance you wouldn’t sit down with the Network Administrator and ask what they want to achieve from the project, however you would ask what project and ongoing role they will be playing with the client and maybe set up a meeting with our own System Adminstrators, so use your own digression.
- Project Manager
- Designer/Design Agency
- Database Administrator
- Lead CMS/Content Editor
- 3rd Party Vendors (existing system integrations)
- Printer
- Creative Director
- Web Developer
- Programmer
The typical number of stakeholders depending on the project
Project Cost Number of Stakeholders £15k - £30k 1 £30 - £50 2 - 3 £50 - £100 5 - 7 £100+ 7+
This is just the tip of the iceberg when it comes to online web project delivery, however I hope it provides you with enough insight and some tips and tricks on how to set the base of the project and make the initial project meetings run a little smoother.