ProjectScopingTips.md

Project Scoping Tips

What?

A collection of tips and suggestions for communicating clearly and effectively with prospective clients or when scoping a new project/ brief.

Why?

Language and delivery are incredibly powerful tools. It is important to use them both thoughtfully to avoid miscommunications and to ensure that expectations are managed well. The aim is that this will result in happy teams all around, no nasty surprises and professional standards.

How?

These notes have been written in the context of a client meeting where you are discussing a project proposal. Some of these notes apply more specifically to a project proposal for a project that has already been started by the client and that dwyl is intercepting to complete. The involved parties are therefore the client and then the client's client which will be referred to as client 2.

Outline the Structure of the Call

Creating structure to a call is both helpful for the client and you. It helps ensure that you both understand what to expect and as a result, hopefully if there's any confusion about this it can be caught before anyone becomes disappointed or confused.

Key times when you should outline the structure of the call are:

• The beginning
• If you are approaching the time at which the meeting is due to end but can foresee it over-running
• The actual end/ conclusion of the meeting

Beginning Outline

You may tell the client that your call will address the following:

• What stage the project is at so far? (Not just as a team but also in more detail technically)
• Trying to answer whether dwyl has the skills required to tackle the client's project
• Ensuring that promises/expectations are clear and can be met, and in the case where client 2 may already be involved, what client 2's expectations are and whether they're currently being (or are on target to be) met.
• The call will end with clear next steps for action.

Time Deadline Warning

• Buy a watch/pedometer with a vibrating alarm, set it for 5 minutes before the meeting is set to finish - looking at your watch will come across as being disinterested.
• If you're meeting is due to end shortly (in the next 5/10 mins) politely make the client aware of this.
• You may at this point wish to revise the structure of the meeting depending on whether you and the client are able to overrun your allotted time and depending on how much content you still have to cover. If in doubt, discuss this with them.

Meeting End with next steps

• Outline what actions each party needs to take in order to progress the next steps. Where possible ensure you outline timings/deadlines for these things.

Early Steps

Ask the Client to Describe the Project in their Own Words

• This is a great way to begin the conversation. It helps you understand the project from the perspective of who you're meeting with (bear in mind that this person may not be the person who wrote the brief). It helps refresh your memory of the brief or inform you if you haven't yet read the brief. It gives you the latest picture of the project which may have changed somewhat since the original brief was issued to you.

Establish how Technical your Client is

• Put your client at ease if they are not technical and let them know you will explain things as you go and that they are welcome to ask when unsure about any concepts.
• Tailor your conversation according to the client's background, ensuring you explain concepts which they may not understand. This will help them feel involved and for them to follow the conversation in order to make key decisions. This will also help them understand better the logic behind creating quotes etc. so that they have a picture of the full technical requirements that go into a project and the time/skill that is required to fulfil these. Ie. this is a front-end feature, this feature is back-end.

Ask to see the Existing Codebase

• If you are joining a project that has already begun, ensure that you ask to see the existing codebase before making any promises. It is worse to promise something that cannot later be fulfilled than to make the client wait a short due diligence period. Avoid unrealistic expectations by ensuring that you have a full understanding of the situation.

• Inspect the history of the project via Github or with the git log command.
  For example git log will return all the commits on the project:

The following options can help to filter and read the commits history:

• git log --oneline will return a succinct view of all the commits

• git log --oneline --graph will display a graph representing which branch a commit was made

• git log --oneline --merges --first-parent master will only display the merged commits into master
  (i.e. merged pull requests)

• git log --oneline --merges --first-parent master | wc -l Finally using the pipe command with the above history log and wc -l (count number of line) we get the number of pull requests merged into master

Establish Expectations Already Set to the Client's Client

• Have any promises/ deadlines been set? Are they on target/ have they already been met?

What are client 2's priorities:

• Does the client believe that all of their requirements will be met or do they understand that there may not be time for all of them?
• If time runs out have made clear what their top priorities are?
• If these priorities have not yet been outlined, request that this is done and explain why it is important with managing expectations.

Establish Deadlines

• Who set them?
• Are they flexible?
• Are they on target at the moment? If they're not, is the client 2 aware of this?
• How did client 2 react to any that have already been missed/met?

Key principles

Time-Budget-Scope triangle

• Try to establish what the client has in mind for each of the points of the triangle.
• Then make them aware that the three points are dependent on one another and that in order to establish a proposal for each of them it is useful to know which points are flexible and which are higher priority/ non-negotiable.

Giving the client choice/ involvement

• Ensure you make the client feel involved by giving them choice where possible. E.g. In a meeting where you're due to discuss 2 projects, ask them which project they would like to start with first?

Honesty

• If you have not had the chance to read the brief in full detail or look at the existing codebase/ product, be honest.

Mirroring, repeating back what you have learned

• When the client explains the product/ brief to you, summarise your understanding from their explanation to them. This helps them know you are listening, creates a time for them to pause and think of what they wish to discuss next and creates the opportunity for you to both spot any misunderstandings.

Indicate dwyl's core principles throughout

• Inform the client of dwyl's procedures when discussing time frames/ quote estimates
• Explain what dwyl does on every project e.g. testing, high quality code, clear documentation, stripping back UI
• Explain what these thing are, why they add value and are fundamental in every dwyl project

Debunk any vague wording in the project outline

• 'Sprints 1 and 2 complete, Sprint 3 ongoing' - The team might be 3 sprints in but what went on in these? How long were they?

Discuss the project brief in detail together

• Go through every bullet point even where you think it may be self-explanatory, this will only add a little time to the process but can clear up assumptions and things that are expressed differently in writing than in words.

Always remain calm and polite

• We can't determine the mood of the person that we are meeting but we can determine our own. If the client is ever stressed or negative about the status of a project, make sure you never let this transfer to you. You may have concerns or questions about how things will be done. However, showing stress and panic to the client will not improve the situation in any way. Help them to discuss the issues more clearly by thinking practically and calmly throughout.

Be generous - offer advice if you think it will add value whether or not you end up working together

• This doesn't mean do half a day of work for free, but good tips that people who might not have managed an app build before might benefit from for example; at best you transmit that you genuinely care about things going well for your client (which you genuinely should) and at worst you've just made both your client and their future developers' lives easier.

Ask open questions / statements when going through the brief

• To encourage the client to add detail and give a clear picture of the brief ask open questions about its details. Sometimes you may find simply reading a line from it and waiting for them to interject and explain this may be effective e.g. 'It says the client's next deadline is next week...' This helps to open things up so it doesn't sound like you're interrogating them but simply asking them to inform you in their own words.

Never bad mouth any of the team

• If ever the client is under pressure (deadlines etc.) and they bad mouth a teammate or dwyl member who is collaborating on the project, do not condone this. You can empathise that time may be short or that there is a lot to do but bad mouthing any individual is not professional or advised.

Do not Give Budget Estimates Before Having Sufficient Information

• Giving an estimate on the fly and later realising that it did not reflect the parameters of the situation fully will have negative consequences. Even if the client pushes you for an immediate quote simply explain that you don't want to mislead them and that creating a proper estimate requires a full picture and consideration of the task. If possible you can tell them when you will be able to give them a full quote by.