Type writer

Naming conventions for project documentation

Standardised naming conventions are really useful for your documentation on a project. They provide a framework and standard for defining documents.

They also make it easier to know at a glance which client or department and project the document relates to, as well as which information is likely to be contained in the document.

Here are my top tips for useful and descriptive naming conventions.

What to include

Include useful information in the file name, such as

  1. Client
  2. Project
  3. Document
  4. Version

Use a hyphen to separate each section. Capitalise each new word to support legibility of phrases without spacing.

Example: [Client]-[Project]-[Document]-[Version]
Example: Ikea-WebsiteRedesign-FunctionalSpec-v0.1

This naming convention can be used for all shared project documents, both internal and client facing.

For longer file names

When you have a long project name, try shortening this to the key notable elements while keeping the project identifiable. E.g. if your project name is ‘Changes to the gift membership templates’ amend this to ‘GiftMembershipAmends’

For internal documents

For internal documents which are not related to a specific project, look to include the following:

  1. Department/team/discipline
  2. Document
  3. Version

Example: [Department/Team/Discipline]-[Document]-[Version]
Example: LeadershipTeam-FinancialReviewMinutes2017Q4-v2.0, or
Example: VisualDesign-WorkshopTemplate-v0.1

Illustrated books

An introduction to Agile

Agile has been around in the digital sphere for years. Almost every agency these days will be promoting Agile project delivery in one sense or another. But Agile can be baffling. There’s so many rules, so much jargon, it can sometimes feel like a secret club that you’ll never get into.

To help you cut through the noise on Agile, here’s my no-nonsense introduction to digital Agile project delivery.


Agile is a framework for how to deliver projects. It’s not a methodology. This means it’s a structure which provides a process for delivering projects, but leaves tools and specific practices open for the user to choose.


There are a few common roles you hear when people talk about ‘working Agile’. A lot of them start with the word Scrum – Scrum is a methodology within the Agile framework. Don’t worry too much about that now. Let’s focus on the basics first.

Here are a handful of the most common roles people will refer to when talking about Agile project delivery.

Scrum master
Essentially a project manager. The Scrum master is responsible for ensuring the project is delivered.

Scrum team
The project delivery team. Normally, a multi-disciplinary team that work together to deliver work.

Product Owner
The client. One client who has the responsibility and authority to make decisions about the project scope, budget and length.


There is a key ideological difference you need to be aware of and adopt when delivering an Agile project. While other frameworks are about the project manager controlling the project, Agile is about a project manager (or Scrum master) facilitating a project.

This means it’s all about making sure people have the right information, tools, touch points and direction to build a successfully functioning piece of digital.


Agile ceremonies are really just meetings that need to happen to work in an Agile process. These typically include:

Daily stand up
A short meeting held once a day with all the project team and often the Product Owner (client).

The same script is followed each day. Each person says what they did yesterday, what they’re working on today and raises any issues or blockers.

It’s designed to allow the whole team transparency on what others are doing, as well as highlight when someone is spending more time than anticipated on something.

Sprint prioritisation meeting
Held on the first day of each sprint, this meeting is attended by the team and Product Owner and in it, work is chosen from the backlog (a list of features, functionality, ideas, technical debt, bugs and tasks) to be completed within the sprint.

Tasks are sized (estimated) by the team to ensure they are committing to the right amount of work.

The period of time in which the team are working on a specific set of tasks. Typical sprints are 2 weeks in duration but 1 week or 4 week sprints are not altogether uncommon.

Show and tell
At the end of each sprint, the team presents the completed work to the Product Owner in a meeting known as a show and tell, wip (work in progress) review, or sprint review.

At the end of each sprint all team members are invited (and encouraged!) to give feedback about how the sprint went.

The idea is to learn from mistakes and successes and feed them into the next sprint to make it more efficient, collaborative, and fun.


There are twelve key Agile principles, but they are really for the hard core Agile lovers who are working on software development. The main things to know and adopt when working Agile are

  1. Prioritise face to face communication and collaboration. This goes for your team and clients.
  2. Sprints are fixed. Once a sprint has started and the work has been agreed in the sprint prioritisation meeting, it cannot be changed or altered.
  3. Be flexible and willing to change direction at the end of each sprint to respond to changing requirements.
  4. Everyone is responsible and all team members hold each other accountable for delivering the project.
  5. Work should be broken down into small increments to make it easy to define, size, assign and test.
  6. Always work with delivery in mind.The idea is to develop working digital products quickly and continually iterate them.


Agile has gained popularity in recent years but that doesn’t mean it’s a silver bullet to project delivery.

Agile works well if you have a dedicated team for the project, an innovative product or evolving scope, a client who is happy not getting everything they want in the first release, enough internal rigour to ensure the ceremonies are adhered to, and a team located in one office.


Do you feel confident running an Agile project? I’d love to hear your feedback in the comments below.

London field

Thank you to London’s fire fighters

This week London has watched in horror as the awful events of the Grenfell Tower fire have unfolded. The scenes shown on the news and the eye witness accounts paint a terrifying picture.

Amongst all the heartache, loss and grief we have seen London firefighters run directly toward danger to help others. London has watched with pride and amazement at their outstanding bravery and unwavering commitment to Londoners’ safety. These men and women have put their own safety in jeopardy to save the lives of others and London is truly grateful.

To support our firefighters Digital Rev has donated profits from Wednesday June 14th – the day of the Grenfell Tower fire – to The Fire Fighters Charity. This organisation offers physical and mental health support to current and former firefighters.

Digital Rev hopes that our donation allows the Fire Fighters Charity to help those who have helped London so much.

If you’re interested in supporting London’s fire fighters why not consider making a donation to The Fire Fighters Charity.


Illustration of Las Vegas sign

Join me at the Digital PM Summit in Las Vegas

Join me this October at the Digital PM Summit in Las Vegas where I’ll be running an interactive session called ‘Money, money, money’.

The Digital PM Summit is two days of engaging presentations, breakout sessions, and lightning talks exploring how we manage digital projects, from a variety of perspectives. It brings together some of the best known speakers from all over the world to discuss, debate and reflect on digital project management.

Tickets are still available for this annual event and if you’re a project manager, producer, delivery lead or anyone else delivering digital projects, this is the place to be.

About Money, Money, Money

I’ll be running an interactive session on the first day of the summit about money.  Managing budgets is a standard part of any project manager’s remit, but how much do we really think about money and how comfortable are we talking about it?

In my 90 minute interactive workshop attendees will explore how and why to talk about money, they’ll understand what profit is, and they’ll discover how to make smart financial decisions when managing digital projects.

My workshop is suitable for all levels of project managers and combines bite-sized master classes with practical hands on exercises and collaboration.

Get your tickets on the Digital PM Summit website.


Question: How do I manage unfinished work?

Hi Peta,

I briefed a developer on some work first thing this morning. We went through it together and discussed all of the tasks that needed to be done. The developer told me he would have the work finished by the end of the day.

At 3pm we had a check-in and he was only half way through the list! He said he’d hit an issue and wouldn’t get everything finished today.

How should I handle this situation? Should I let it slide or let him know he should have got the work finished on time?

Mark – Junior Digital Project Manager

Great question, Mark. This is a really common situation that project managers find themselves in. Lots of our job is managing expectations, and that doesn’t just mean managing our team’s expectations about the pace of the project and their own work, but also what happens when this expectation isn’t met.

There’s a couple of ways you could handle this, depending on the person, the work and the impact:


The first thing I’d consider is if this is common behaviour for this person. Have you found this developer is consistently late in delivering work no matter how complex or easy the work is, or how much time they have?

If working with this developer is like groundhog day and always ends without a delivery you definitely shouldn’t let it slide. Not only that, but you should raise it with the developer’s manager or the project’s technical lead, in addition to your manager.

But, before you go charging off to put things right, stop and think for a moment about whether this person is always missing deadlines because they don’t have the skills or support to deliver the work or the knowledge to size tasks correctly. Or, has this person checked out and doesn’t care how their work impacts the wider project and team. Having a view on this will help you frame the conversation with your seniors in the right way.

If your developer usually delivers well and on time, and you feel they have done their best and have been upfront and honest with you, think more about the work and project before making your decision.

The work

You don’t mention what the work is that you briefed, but there’s a huge variance in the type of tasks we ask our developers to complete and the complexity of them – all the way from making changes to a legacy system with inconsistent and unintuitive naming conventions, to architecting a brand new solution, or BAU bug fixes.

If you were to draw out two intersecting axis, one axis representing time (quick, lengthly) and the other complexity (routine and easy, or novel and difficult),  which quadrant would the work your developer was tasked with fall into? For more difficult or lengthy tasks it’s much harder for team members to estimate accurately.

If it’s legitimate that the work was straight forward, routine, easy to understand and execute then you can fairly challenge why it wasn’t completed. If the work is unknown, novel, or difficult you should be a little more sympathetic and assess the impact of late delivery.

The impact

When considering if you should let late work slide I would consider what impact it has to the project. Has this incomplete work meant, a missed client deliverable, a reasonable impact to the project budget, an alteration to the project timings, scheduling conflicts for other projects, or a cumulative impact of two or more of the above?

If the unfinished work means an impact to your agency, the client, other projects, or other people on the project you should at the very least make the developer aware of the knock on effect. They are part of the project team and they should know how their actions or omissions impact the wider project and delivery. If the impact is minimal or non existent then I would be inclined to let it slide.

In summary

People aren’t robots and they can’t do everything perfectly every time. Sometimes we make mistakes, have an off day or just get it plain wrong.

Team transparency and the ability to be up front and honest is paramount to running a successful digital project. Within reason, you should encourage (and never punish) this when it happens.

If you find however that you have consistently missed deadlines and apathy for straight forward work which is impacting your project (or any one of these things) don’t let it slide – start the conversation about why this is happening and how to resolve it.


Silhouette of talking heads on a library background

Featured on The Digital Project Manager site: 5 Simple Steps for Handling Difficult Conversations Better

Check out the Digital Project Manager website where you can find loads of great DPM resources, with everything from agile working practices, to time keeping, training and more. You can also find my latest article discussing how to manage difficult conversations when running digital projects.

In my article, ‘5 Simple Steps for Handling Difficult Conversations Better’ I share tips such as what to know before you start, where to have an awkward conversation, who can help you, how to structure a difficult conversation and why they’re important to running successful digital projects.

Don’t forget you can also book Digital Rev to run training for your project managers and delivery leads to teach them how to better handle difficult conversations, with a focus on project finances and team performance. Take a look at the workshops page or get in touch for more info.

I’d also love to know what your best tips for handling difficult conversations are through the comments section.


Agile Inception techniques

Agile project inception techniques

You often hear agencies talk about running ‘agile’ projects which usually ends up being hybrid wagile or planning + iterative development. Lots of agile books dive right in to delivering the project, mid-code and everyone on board. So one thing that interests me a lot is how to run a truly agile project inception. I was lucky enough to attend DeliverConf’s 2017 workshop day in which Delivery Director at Valtech, Kevin Murray, discussed this very topic.

As it turns out, truly agile project inception is actually a lot more similar to waterfall in its aims than you may think. You still need to understand your client’s business, their users, stakeholders and objectives. You still need to find a good digital solution which is feasible and realistic. You still need to gain buy-in, confidence and build the foundations for the project delivery. What was in stark contrast was the amount of collaborative exercises that are done with the team and client as well as the role of the project manager. I’ll explore a few more of these exercises in depth below, but here is a photo of all of the agile inception techniques that Kevin may draw on when starting a project.

Agile Inception techniques

One really interesting thing Kevin mentioned was that running an inception phase with this approach meant it was okay for a client not to have all the answers. Typically in waterfall we ask a client to drive the development of a list of requirements (especially for cost reasons if there’s a tight budget). This puts the assumption and risk onto the client that they must have all the answers immediately and up-front. I’ve seen first hand that this can fill clients with ‘project FOMO’ or make them overly and unnecessarily lofty and abstract in their requests.

So, what agile inception techniques are available to help clients (and teams) who don’t need to know everything right here, right now?

As you guessed from the name sliders are a set of criteria which can be assigned a value (e.g. 1 to 10). Clients can slide the values higher or lower to demonstrate which criteria are fixed, and which are flexible. For example, your client may say that accessibility is absolutely fixed, but security is flexible. Such a site may exist for a marketing site for a charity which supports the deaf-blind. It has high accessibility needs, but as a marketing site doesn’t need Fort Knox security.

An add on from me, would be to set the values between 1 and 10, with 1 the most flexible and 10 the least. Then, times the number of criteria by five (e.g. 10 criteria x5 = 50). The total here gives you a total amount of points which can be assigned amongst all criteria in order to determine the relative flexibility or rigidness.

If you find your stakeholders really struggling with the number of points they can assign it’s a good indication that there are too many fixed elements and that either something needs to change at the stakeholders end, or you should have a conversation about whether agile is the right delivery framework for this project, at this time.

If your clients can assign all of the points and come to relative consensus on them, you have a great understanding of the project’s priorities in order for it to be successful.


Assumption mapping
Assumption mapping allows everyone to have a say about things which either seem really obvious to them, or feel a bit risky because they don’t know the answer. It’s a great technique for when there is a shared and understood idea about what you’d like to do for the delivery phase.

Take a big sheet of paper and draw an intersecting x and y axis. Name one axis Certainty, and one Immediacy. Ask all your stakeholders and team to begin jotting down their assumptions onto post-its. It’s okay if you have loads – that’s the idea! Better to ask the question now than be thwarted by an assumption later down the line.

Once your stakeholders and team have a good list of assumptions ask them to start placing them into the relevant quadrant – certain and immediate, uncertain and immediate, certain but not immediate, uncertain but not immediate.

  • Certain = how sure are we that x is feasible?
  • Immediacy = how urgent is this feature to include in the MVP?

Once you have a finished and well debated map, you can pass it over to your team for technical, user, and business analysis and investigation. The aim is to move everything out of the immediate and uncertain quadrant either by establishing its feasibility or by de-prioritising its immediacy. This will help you generate a first draft of features and stories before committing them to a more formal backlog.

Assumption map

Vision statement
A good tool to sense check thinking and collective understanding of the proposal is the vision statement. Done well, it guides the project, working as a checkpoint for feature proposals, objectives, and product or service aspiration.

Best used once you have completed some initial brainstorming and research, it works simply by following the formula and filling in the blanks:

  1. THE (name of product/service)
  2. FOR (users of product/service)
  3. WHO WANT (key features of the product/service)
  4. THIS SERVICE(S) WILL (sub key features)
  5. UNLIKE (existing/competing product/service)
  6. THIS SERVICE WILL (key differentiation/advantages of product/service)

The idea is to get to a vision statement that everyone agrees sums up the aspiration.

Vision statement

Apart from the above inception techniques one of the things I took from Kevin’s workshop was the level of involvement the UX researchers, business analysts and client stakeholders have in the inception period. As well as the need to have good quality users available at relatively short notice to ‘real-world sense check’ ideas. Additionally, the role of the project manager in this stage was far less about planning and far more about facilitating workshops, conversations and exploration.

You can view Kevin’s full presentation on slideshare.

I’d love to hear about any agile inception techniques that you have used and have found to be really successful.


We Need to Talk – DeliverConf workshop 2017

A huge thank you to DeliverConf 2017 for another fantastic 2 days of workshops and talks.

This year I ran a three hour workshop for 43 delivery professionals from the UK and Europe called “We Need to Talk“. Participants learnt how to handle difficult conversations when running digital projects.

In the three hour interactive session we looked at ways to handle difficult, awkward and down right uncomfortable conversations, with a focus on team performance and project finances.

By the end of the workshop participants had flexed and strengthened their communication skills as well as developing their project leadership capabilities allowing them to handle even the stickiest situations.