Choosing the right tool for the job?

Published by Mel Joy on behalf of Ian May. Check out or hit Ian up on Twitter at @ThatIanMay

Project Managers love talking about tools, almost as much as we love a good methodology or people discussion. So how come making a decision about which App or package to use sometimes presents such a dilemma? And how should you go about making an informed choice?

I guess part of the problem is fear of making a poor decision. Then there’s also the nagging doubt that you haven’t looked hard enough to find exactly the right thing to help solve your problem in the short, medium and long term.

I was recently faced with a similar challenge so here’s how I solved the problem.

I’m starting my own business offering support to agencies and managers with digital project management problems. It’s essentially a consultancy where, for the moment, I’m going to be working on my own. I’m reasonably good with financial management but I don’t have a background in accounting and I needed a tool to help me deal with invoicing, expenses, cash flow, tax and the operational side of running the business finances.

As I saw it there were a couple of routes to choosing a solution:

  1. Internet research
  2. Asking my personal network for recommendations
  3. Speaking to my accountant or the bank to see what they suggested

I started with 2. And then I followed up with 1. I may still try 3. but it’s early days in the relationship and, rightly or wrongly, I trust the advice of my peers over and above anyone else’s.

The great thing about being part of the Digital Project Management (DPM) community is that you have access to a bunch of clever, helpful people. So I quickly had some recommendations and the beginnings of my dilemma – which one of these great tools to pick? At this point I knew they probably wouldn’t be free to use but I hadn’t considered price as a factor.

The other thing I’ve been doing is as much reading and research as possible trying to understand what’s important when you go freelance. So I listened to a number of the Boagworld podcasts about starting your own web design business (Season 12?). Paul Boag is well known in the industry and he uses and recommends a platform called FreeAgent.

Soon I was down to a shortlist of 3:

  1. Xero
  2. Kashflow
  3. FreeAgent

I suppose what I should have done was find someone I know who’d tried all 3 and ask them which they found best!

Faced with a knowledge gap and no-one to ask (it was a Saturday night and my DPM friends don’t love me that much!) I did what I think most people would do: Googled it.

Fortunately I found a couple of useful things pretty quickly: a Blog post article comparing Xero to Kashflow and FreeAgent discussing the problem I had, and a site called GetApp which offers a comparison service for web apps.

At this point I also did the other thing that people in my situation often do and opened each of the possible vendors websites in a separate tab to find out what they had to say. I liked what I saw. It’s obvious that the companies have put a lot of thought into their products and marketing them. And I could see straight away that this kind of tool was exactly what I needed. The question was which one?

Pricing of the 3 products is on a pay-as-you-go basis and each also has a free trial available. The problem was: I hadn’t got time to try them all out – even though investing in one of these felt like a big decision and I wanted to get it right.

So why, oh why, did I pick to try out the most expensive one?  I think it was a combination of these factors:

  1. On the GetApp comparison chart my second favourite tool was missing a feature that I think might come in useful in the future
  2. It was the one that Paul Boag recommends (and I suspect my business will be operating in a similar way to his)
  3. I’ve always believed in the maxim ‘buy cheap buy twice’ and seeing as there was a free trial I figured it was worth a go!

It’ll be really interesting to see how the experience turns out, and whether I stick with my choice.  Watch this space…

If you’ve faced a similar dilemma, why not tell us about it (and how you solved it) in the comments.

Stress, relaxation….and a new venue


Wed 15th June saw DOPM try out a new venue at the Wig and Pen in Oxford. Personally, I’ll miss the charm of the howling dog and the mouse-eaten Christmas decorations that came with the White House… but some people have higher standards than me it seems.

Despite the appalling rain, the turnout was great and there were a few new faces, so hopefully the more central venue works for everyone (please let us know what you think).

The Evening kicked off with Stephen facilitating a session on stress, stress triggers and how we can resolve them. It was meant to be co-run with Ian May, but the stress of Oxford traffic delayed his arrival… (oh the irony).


It’s testament to the openness of DOPM members that this ended up being a really honest and insightful session. It’s all too easy to be blaze about our jobs and forget that stress accounts for about 35% of all ill-health cases at work. Most people will know someone who has been personally impacted by severe stress (or they will have had this grim experience theirselves).

Slides for this talk are here:


Following this was the amazing Calliste giving her inaugural DOPM talk. It was a screen-free zone as we got amazing flip-chart sketch notes to accompany her honest and inspiring talk. There were numerous nods in the audience as Calliste recounted an all-too familiar tale of late hours, juggling numerous balls, ill-health and essentially putting too much value/attachment on ‘a job’.

Thankfully the story had a happy ending. You can read Calliste’s blog on this subject:

What really hit home for me, was the need to enjoy my free time more and do more things ‘for me’. A great insight I took away was to ‘think about the stuff you liked to do when you were ten years old’ as its highly likely that stuff still provides great enjoyment and stress relief for you now (e.g. football, art, comics, writing being silly).

Finally, it all got super-groovy and we took off our shoes to become uber-relaxed and completely de-stressed with the the amazing Laura Sewell from Resonate Yoga.

It’s hard to cover what we did… breathing in and out doesn’t make for good writing, but this was a massive hit for me. I left feeling really chilled and since that point I’ve signed up for Headspaces’s free 10for10 program . Along with some other changes I’m making, I’m kind of hoping this could be the start of some big adjustments in my life that lead to positive outcomes.

So friendly people, brave and intimate tales of dealing with stress, life-changing stillness and free drinks courtesy of Austin Fraser and Gather Content… I’d say a pretty good night all in all.

If you’re not already coming to DOPM… you really should. If you already come, please keep spreading the word… there’s something good going on here.





An Introduction to Servant Leadership….and more

Wednesday the 10th of February marked the first DO PM of 2016. It reminded me that ‘the DPM meetup idea’ we had back in Autumn 2014 has since become an established event which has been running for well over a year.  It’s been really great to see a consistent crowd of familiar faces and every event always brings a new arrival and more often than not we receive lovely feedback like this. Screen Shot 2016-02-19 at 12.30.45

To kick off 2016 we were really lucky to have Gez Smith, talking about Servant Leadership. Rather than me writing about it. You can watch the whole talk below (another first for DO PM – our first recording):

Gez is director of Bunny Picnic, which offers training and consultancy in agile servant leadership and agile communications. Find out more at

My key takeaways were:

  • Servant Leadership is a topic that has a depth of academic thinking behind it
  • Being a servant leader is extremely challenging and while its a likely path to personal and job satisfaction it doesn’t always mean you will do well in your career especially if you are in organizations that don’t value servant leaders
  • Many organisations are structured to put the needs of the CEO first and the needs of the customer last
  • Being a servant leader can turn the job of PM or Scrum Master into a deeply fulfilling, almost spiritual vocation.

It was a great talk and certainly inspired a number of attendees.

Following up for Gez’s talk we were lucky enough to debut two new speakers. One of our missions for 2016 is to have more talks from within the DO PM community and to provide a safe space for people to talk for the first time.

Melissa Wilson was brave enough to become our first new speaker of 2016. Melissa is a DPM at Incuna and gave a fascinating talk on the perils of transitioning an agency from a waterfall process to an agile process. Melissa has done an incredible job at Incuna often having to go ‘undercover’ to show how certain agile processes would benefit the wider company. once the results of these had proved themselves they were quickly adopted.

You can view Mel’s slide – complete with awesome cat Gifs here:


Charlie Davidson, DPM at Ridgeway Digital gave a fascinating round up of DPM:UK 16. His talk showed how the DPM community is growing year on year in the UK. There were so many knowledge shares from his talk that we can’t reproduce them all here, but it was testement to what a thriving, exciting industry it is to be part of.

Our next event will be in April, follow us on Twitter or sign up to our mailing list to stay informed.

DO PM goes Kanban Crazy


Wed 17th June turned out to be a great night for DO PM. We had a really good turnout and the feedback we received was very warm and positive.

We were looking at the subject of Kanban; both its origins and how its principles affect our day to day work. The evening started with Steve ‘Danger Zone’ Thomas introducing a potted history of Kanban and some of the principles behind it.

His slides are available here: Kanban Slides

Following that Anthony Glass introduced the first of the night’s activities. Teams split into groups of 4 and had to follow a process, involving four distinct sets of task.  The activity was based on the lego activity here:

Kanban Lego Game

FullSizeRender (1)

Following two round of this game, we learned some valuable lessons.


In the first run through, teams followed no system which lead to major bottlenecks at the third stage of production. In the second run through each station was only allowed to start their next task once the previous station had picked up their delivery. This began to iron out the cycle time.

The results were really astonishing. The second method had a lot less work in progress (as you might expect) when the time ran out, but most of the teams actually ended up producing more goods. Primarily because there was less stress, and less clutter building up on the table. You could argue that teams became more efficient through experience but overall it was a really effective demonstration of how a well organised system can improve production.

The next game related to batch sizing. It was based on the coin game detailed here:

Coin Game 

Teams of 4 had to flip over 20 coins before passing them onto the next station. We started with one batch of twenty and then gradually reduced the batches to 10, then 5 and then let teams pick their own process. Not only did it show that smaller batches resulted in significantly faster production rates; this was also a good demonstration of continuous improvement – as teams were having mini retrospectives at the end of each round as to how they could improve their process.

Overall it was a great night and a fun introduction to the principles behind Kanban. We didn’t really have the time (or expertise) to get into a detailed breakdown of how to run Kanban software projects, but we have included further reading for those that want to pick this up and take it further. Judging by the enthusiasm for last night’s session, it may be that we choose to revisit Kanban at a later date with a guest speaker or a more specific focus. Leave a comment if you’d like to see this or have any further suggestions for meet-up topics.

Useful web resources we referenced

Recommended Reading

Please post any other useful resources you know of in the comments

Resourcing Tools: Float, Forecast and Resource Guru

So you need a tool to organise your resource…

There are so many great resourcing tools out there in the market, where do you begin? Before choosing a tool, it is important to ensure you understand your requirements.

  • What kind of resource do you want to display?
  • What data do you want to capture?
  • Do you want to show long range forecasting?
  • Can you obtain the metrics you need to measure against your production team?

We have recently been trialling resourcing tools, so I had a chance to play with Float, Forecast, and Resource Guru. I’ve put together a short summary comparing all three tools which is detailed below, but for now here is the scoring method I used, and how I drew my conclusions.

There are many examples of “Competitor Analysis” spreadsheets that can be easily found on the web. A heuristic spreadsheet will enable the user to input data which gives a metric to measure how good something is against. Once you have identified your requirements from a resource tool, think about the kind of questions you can ask of each tool – can it show you a long range forecast? Is there a dashboard?

The questions were measured against a numeric value between 1 – 5 with 1 being very bad and 5 being the perfect score. The questions were ordered according to priority 1 – 3 and therefore the number given as an answer will be multiplied by the given amount above each section to give adequate weighting.

Competitor analysis

Figure 1. Competitor Analysis Spreadsheet with questions

Once you have your calculations for each tool, there will be a numeric value which will identify the clear winners and the ones that come close. Within this data there will be key factors that explicitly say if a tool was good or not at a particular task which allows the analyst to make a clear decision on if the tool meets their requirements. Using this data you can draw up a list of pros and cons for each tool, helping you define your argument and final executive summary of your decision. Below is a list of questions that were asked of each tool to compare their capabilities:

Priority 1 – Multiply all your figures on the scale of 1 – 5 by 1.5

  • Does it show accurate utilisation stats %?
  • Can I give access to non-production team members or mark them as such in the tool (avoiding stats distortion)?
  • Can I see gaps easily?
  • Is it easy to add people to projects?
  • Is it easy to extend tasks for people?
  • Is it easy to split tasks for people?
  • Is it easy to move tasks from person A to person B?
  • Can I group people in a flexible way?

Priority 2 – Multiply all your figures on the scale of 1 – 5 by 1.25

  • Is it easy to add projects?
  • Can I see 3 weeks or more in the detail view?
  • Roadmap for upgrades?

Priority 3 – Multiply all your figures on the scale of 1 – 5 by 1

  • Can I put comments on tasks?
  • Is it easy to add people?



First up we have float which boasts that it is “Team scheduling done right. Manage your teams workload without it feeling like work”. You can read up about all their key features here but how do you know if it is the right tool for you?

The scores on the doors suggest that it was a close call between Float and Resource Guru. Here are some of great features of float that aligned with our company needs:

  • Excellent reporting function
  • Gaps can easily be identified with 3 weeks or more seen in some detail
  • Easy to add people to projects
  • Easy to extend tasks for people
  • Easy to move tasks from person to person
  • Easy to add projects and people
  • Easy to add comments to tasks
  • Good roadmap for upgrades – Continuous support and improvements to the application



Those of you that are familiar with Harvest will recognise similarities in the branding of Forecast, this is the sister application from Harvest which claims to “Map out your plans and see them with clarity in Forecast. Know how busy or available your team is at a glance. Keep key dates on top of everyone’s minds as you push projects forward”.

We’ve been using this tool for a while now and although it offers some good functionality, it wasn’t the favourite to win. Find out more about the features here and see below for some of the pros for this tool.

    • Easy to extend tasks for individuals
    • Easy to add individuals to projects
    • People can be grouped in a flexible way
    • Easy to add projects
    • See three weeks in advance
    • Easy to add people
    • Easy to comment on tasks


Resource Guru

Finally we have Resource Guru, something we have been trailing alongside Forecast for a couple of months now and it’s message is “Resource scheduling, the easy way. The fast, simple way to schedule people, equipment and other resources online… finally!”.

Personally, I am a fan of the bright colour scheme but I am a little biased, my favourite colour is green. Find out more about specifics here and check out the pros listed below.

  • Good reporting function – accurately see utilisation stats
  • Easy to add people to projects
  • Easy to extend tasks for individuals
  • Easy to split tasks
  • People can be grouped in a flexible way
  • Tasks can very easily be moved from person to person
  • Easy to add people
  • Easy to put comments on tasks
  • Projects can be added easily
  • 3 weeks or more can be seen in detail
  • There is a dashboard view


My executive summary is shared below for those of you who are interested in words rather than metrics determining a cold hard winner, it is clear that this is not a simple yes or no answer.


Forecast does not meet our current resourcing needs, no reporting function coupled with no plans for improvements on their features suggests that this service will not improve in a way that suits our requirements.


Resource Guru and Float come very close to our requirements, however, neither are perfect. What is promising with Float is that there are several new improvements being made and readily documented throughout their blog, Resource Guru last posted on webhook integrations in February and most encouragingly mention integrations with Slack being on their radar in the near future.


Resource Guru and Float both allow the potential for long range forecasting with detailed views and the ability to comment on tasks to offer supporting notes. Utilisation statistics are a major factor in improving production, Float offers a sophisticated break down of utilisation by project and individuals, however, it does not take into account if an individual joined half way through the year or started not working on a certain day of the week. Resource Guru allows you to take into account if an individuals working pattern changes at any point in the process without misrepresenting the figures. 


Adding projects and people to both Resource Guru and Float is a very easy task and swapping tasks between individuals can be done with a simple drag and drop. Extending an individual’s task can be done by selecting and dragging through the amount of time the task is extended to.


While both Resource Guru and Float score high in our requirements, Resource Guru has a dashboard, a sophisticated reporting function and are integrating the addition of making some members non-production so it will not affect the numbers which will be beneficial for HoP in terms of utilisation of production members with long range forecasting. Final scores for Float comes in at 68, Forecast 54.75 and Resource Guru 74.25.

How Wireframes Are Hurting Your Designs

Wireframes are still for many a part of the website and mobile app design workflow. But there’s a huge problem: static wireframes are no longer fit for purpose. They’re compromising your design process and the interactions your users have with your website, making life difficult for those users.

Wireframes need to be replaced in all web design and build projects with something much more suitable for today’s way of working – and more importantly that meets our customers’ changing expectations.

What Are Wireframes For?

Before we start analysing their worth, let’s look at the purpose of wireframes. They are essentially skeletal frameworks that illustrate three aspects of a website or mobile application’s template:

  1. Functionality
  2. The hierarchy of this functionaltiy
  3. The layout of this functionality

They complement a functional specification: while the spec is a document aimed at making the technical clear, the wireframe aims to make the experience clear. Importantly, they let you think about the importance of different pieces of functionality and of layout without the distractions of colour and content.

The problem with wireframes is really twofold:

  1. People struggle to understand this purpose
  2. The purpose itself misses out hugely important aspects of digital design

Wireframes Make Understanding Hard

I’ve taken many clients through many wireframes, and I’ve lost count of the number of times even the tech-savvy among them have said “I’ll be able to get a much better feel for this layout when there’s some proper images and real copy there”. Remember when we said that a wireframe is there to help you understand functionality without the distractions of colour and content?

It’s a real challenge getting clients to understand that wireframes are mostly about what a screen does, and only a little bit about layout. The penny often drops part of the way down when the client reads the spec, but even if they go through the documentation in minute detail there will be a gap between their understanding of functionality and their understanding of form and information hierarchy. This gap results in a corresponding gap between what is produced and what the customer needs – reducing engagement, loyalty, and RoI.

Wireframes Ignore Interaction

We often think about design through the prism of form. But form without function is art, not design. There are four aspects to design, which can be thought of layers building one on top of the other:

  1. Outcome
  2. Structure
  3. Interaction
  4. Visual

All of these layers work together with just one aim: to solve a user’s problem.

Of course we’re always (ahem) driven by the “outcome” layer. Wireframes – with their purpose of outlining functionality, hierarchy, and layout – cover “structure” nicely. And taking the wireframe and making a hi-res design from it takes care of the “visual” layer.

But what about interaction?

Wireframes and static design comps between them do nothing to illustrate how the user will interact with the screen and how the screen will respond. You can add basic state changes, like hovers or active states, to a comp but that’s about it. You can’t show the expansion of an icon to a popout, or how an animated SVG will bring life to a page. You can’t demonstrate to a client how parallax scrolling can work for them, or how a menu will push content out when expanded.

Getting the interaction layer right is essential if you’re going to give your customer something they will actually want to use – to interact with. As Google say in the rationale for their Material Design approach, “motion provides meaning”. Static wireframes and comps can never replicate motion or anything but the most simple of interactions, removing thoughts about interaction from the design process almost entirely.

Google’s material design considers how motion provides meaning, bringing interaction to the fore in planning  (image credit: Google)

Wireframes Force Compromise

Mobile-first design is a philosophy that has taken over the digital design world over the last few years, and has become fundamental to how many of the best designers work. One of the most important aspects of mobile-first design is information hierarchy, because with so little space on a mobile device each pixel of that space becomes very important. This means mobile-first design has to start when we’re first thinking about information hierarchy; traditionally this means at the wireframing stage.

The importance of information hierarchy on mobile devices (image credit: webdesigner depot)

The difficult part comes when we expand the list of screen sizes to encompass all the devices our customers might use. To do this we need to work across screen sizes, from teeny-tiny iPhone 4 screens to 62” 4K TVs – which is a real pain with wireframes. Each time you get to a new screen size you essentially have to start your work again, so a site with four breakpoints requires four distinct sets of wireframes. And who’s got time for that?

So instead you pick a screen size, wireframe for that, and take care of the rest in design. But this approach means you don’t start by thinking about mobile devices – their tiny screens mean there’s no way we can cover the layout aspect of a wireframe if we do that. Instead we start at a nice, large resolution – 1024px, say. Because you’re comfortable with that, and it’s a compromise. Because we have to start somewhere.

And that’s where it all falls down.

You, like our client, start to focus on layout, and forget how important information hierachy is to mobile users. You stop thinking about the people sitting in front of their smart TVs, and how different their experience is to that of people on their laptops. As a result you start compromising on all of their experiences.

Screen sizes are completely fluid, and your customers expect their experience to be perfect whatever size of device they’re using. If you’re going to start somewhere don’t pick an arbitrary size because you’re comfortable with it. You need to think about the minimum your customers will be comfortable with and extrapolate out from there. But like we said earlier, you can’t really do that with wireframes. Or at least not without an awful lot of work.

Have We Really Not Found Anything Better?

Wireframes have been around for decades. They’re a hangover from the days of print, from when the men on Fifth Avenue wore fedoras and suits. From when catalogue ordering was the height of sophistication and when Tim Berners-Lee was still in primary school.

Things have changed rather a lot since then. Amazing new technologies and tools have come, and are continuing to do so all the time: The management environment has been revolutionised, with the introduction of the open office, Agile practices, and 360 degree reviews: content and inbound marketing have forced a paradigm shift in how marketers think and work. Along the way customers’ expectations have evolved beyond recognition, as has the way they experience brands. But the wireframe remains the same.

If we’ve been able to change the faces of huge, broad disciplines like manufacturing, management, and marketing, have we really not along the way been able to improve how we represent structure and functionality of a web page or app screen? I’d like to believe we have.

I’m not the only one to think like this. The strategic giants at Adobe seem to have been of the same opinion when they retired Fireworks a couple of years ago. There’s also an excellent blog post from Paul Addams on Intercom about the Dribbblisation of Design, and central to his argument is that “Designing static, linked web pages is a dying profession… PDFs full of wireframes are a dying deliverable”. All of which is, I think, great news for everyone involved in digital design and build – and even better news for our customers. It all also points to the fact that there is something better out there.

The Wireframe is Dead, Long Live the Prototype!

If the wireframe should be scrapped because they’re hard to understand, make us forget about interactivity, and restrict us to one screen size in our workflow then we need a solution that helps people understand our process better, encourages interactivity to be part of our workflow, and helps us think across screen sizes and device types. Enter the prototype, stage left.

Prototypes have essentially the same purpose as wireframes, but they add an extra aim: not only are they a tool for demonstrating functionality, hierarchy, and layout, they are also a tool for exploring interaction.

Prototypes are easy to understand

We’re creatures of imagery and stories. We find it much easier to understand something if there’s a narrative behind it. The reason clients don’t understand wireframes is that it’s very difficult for them to understand the story you’re trying to tell.

A prototype that lets you scroll, click, and experience the user’s journey on the other hand tells a powerful narrative, and so helps clients to understand what they’re making decisions about. Importantly this also helps us to understand that narrative, and in understanding it to make it better.

Prototypes are dynamic

The thing I love most about prototypes is that they’re dynamic. You can get a true feel for the user journey, whether that’s moved along by clicking between pages or by scrolling.  You can create interactive elements to show exactly what happens when a user starts a video playing, or how scrolling will control the parallax effect on a background. In short prototypes allow you to move beyond thinking about the Structure layer and onto the Interaction layer – the part that wireframes failed to do.

Prototypes span screen sizes

Remember we said that the reason that mobile-first design and wireframes are incompatible is that you essentially need to redo your work if you start wireframing for different screen sizes? One of the joys of prototypes is that you can use the same elements at different sizes, modifying them where needed. This makes mobile-first thinking and working much easier, and so encourages you to create a better experience for all your users.


I think wireframes should be confined to the past. They’ve outlived their usefulness, and in today’s digital landscape don’t have a place. They are restrictive, hard to understand, and stop us from addressing users’ needs. Importantly, workflows based on static wireframes and static designs constrict our thinking about interaction, a key part of the user’s experience.

Prototypes, on the other hand, help us to think about interaction opportunities. They also help us to think about user journeys and emphasise the hierarchy of content and functionality. Prototypes are and should be the future of web design.

Vive la révolution, et vive l’évolution!

Launching Digital Oxford

We’re rather a busy bunch at the minute. While some of the DO PM crowd are up at DPM:UK 2015 – Stephen has even been speaking there – those of us still in Oxford have been at the launch of Oxford’s biggest new digital initiatives.

Digital Oxford aims to showcase the city (and county) as a world-class digital destination – and judging by the amount of attention the launch received they seem to be off to a good start. There was coverage in Wired UK before the event, coverage from BBC South Today during, a supporting message from an MP , and a move to a bigger venue because so many people wanted to be there.

At the launch we were treated to talks from Thorsten Reil and Dave Fletcher, and to demo’s from Oxford-based startups like Solid State Logic and MySociety, as well as a free bar thanks to the event sponsors (always appreciated). All of the people and the activity there made us feel that Oxford should be pushing for that “world-class” status.

Thorsten Reil, founder of Natural Motion, at the Digital Oxford launch event, talking about the mobile game developer’s history and genetic algorithms (image credit: Laurenti di Medici)


So what does Digital Oxford’s aim mean for us digital PM’s? Hopefully over the next few years it means there will be more outside investment in Oxford’s digital scene, more jobs in the industry, and more people to learn from. Which can only be a good thing.


Technology capability continues to grow at an exponential rate. From Moore’s Law to Gilder’s law, well-known trends provide ample evidence that there will be no plateau in the use of increasingly complex technologies.

By Wgsimon (Own work) [CC BY-SA 3.0 ( or GFDL (], via Wikimedia Commons

The social effects are just as astonishing: ten years ago the job of app developer, big data analyst or cloud services engineer didn’t even exist. Any of today’s children destined to work in the tech industry in twenty years time will be working with languages and tools of which we currently have no concept.

This continual journey into the unknown is what makes working on digital projects so exciting; and what makes estimating digital projects so tricky. For most people, knowing how long it’s likely to take to walk to the nearest bus-stop is easy because it is they’ve done it before. However trying to guess how long it might take to walk 50 miles due North proves far trickier as:

  • a) it’s not something you’re likely to have done before
  • b) the margin of error is far greater due to the time and distance involved.

Most software projects of a reasonable size deal continually flirt with the unknown. This makes estimation hard and provokes the question of how to structure a contract when the exact approach  is yet to be worked out.

Traditional client/agency models have centred round a fixed price model, whereby the development team are held accountable to their initial estimates despite not yet possessing all of the information they need. While you can add in contingency to mitigate risk there are still some key flaws with this model:

  1. It’s very hard for client and vendor to avoid an optimism bias at the start of any project and this subsequently places most of the risk on the vendor
  2. If a client expects fixed price and fixed timescales then the only thing that can shift is quality – leading to a product that nobody wants.
  3. This type of contract can lead to an ‘us versus them’ scenario where budgetary pressure gives way to hardened attitudes between client and vendor about ‘what was said’ or what constitutes a change request – essentially it can be a collaboration killer

That’s not to say fixed price can’t be done well. Some companies manage this model extremely well. However, it doesn’t push you into exploring the unknown but is more likely to lead you into seeking out safe ground. This can kill off creative ideas before they’ve been given a chance. Lastly, if you speak to any PM about ‘fixed-price projects’ you’ll occasionally  see an ‘a thousand yard stare’ come across their face as they remember the hardship such shackles can sometimes impose on running an innovative project successfully.

Thousand Yard Stare


At the opposite end of the spectrum is working on a time and materials basis. Many agencies do this extremely well. Their reputations and experience encourage clients that continually fund the team till the project has ended despite their being a slight fuzziness as to what the exact bill will be. However, the flaws with this include:

  • The balance of risk is all on the client – They have no guarantees that their budget will be able to deliver them all the features they need to fulfil their business aim.
  • T&M can be erratic – it’s hard to actively manage a backlog when one sprint can suck up a huge amount of time but deliver very little in terms of releasable software; while other sprints deliver a lot more for less dev work. How can you assess the value of a feature when you can’t be sure of its final cost.
  • T&M doesn’t promote efficiency – Any contract where you get paid more for taking longer isn’t really delivering a positive subconscious message about working lean
  • Even if the client has unlimited budget, T&M projects can result in wooly decision making – there’s no fixed end point, so there’s no pressing need to make clear, timely decisions that fit with a lean build.

I’ve had experience working with both sets of models and have found various ways around the problems they can pose. Currently though, I’ve moved to a relatively new model that works well for us and our clients

I call this the Price Per Point model but it’s also know as Fixed Feature or Price per Feature:

  • Functionality is broken down into discrete user stories and we estimate these according to how long/how complex it will be to deliver every aspect of that story: design, UX, development, PM, AM testing, refinements.
  • We estimate these stories in story points. Using points gives us a method of estimating stories in relation to one another rather than fixating on exact times (e.g. it’s easier to estimate that the train station is twice as far away from your house that the supermarket than it is to estimate the exact distances in km).
  • Before starting development as a team we review the initial estimates after a sprint planning session. This gives us a chance to update our estimates based on the very latest knowledge. It can also give the client a chance to add further acceptance criteria, split or simplify a story.
  • Once ready we begin work on the story and progress it all the way through the stages of production until it is at a stage where the client can sign it off before it is pushed to a live site.
  • The client pays a fixed cost for each story point and doesn’t pay a thing until the story has met with their approval and has been fully signed off.

The reaction from clients to structuring billing in this way has been overwhelmingly positive. The key reasons being:

  1. There is a really clear definition of done i.e. Client’s must sign off each story on a staging or live site in accordance with acceptance criteria that they have written
  2. Clients are in control of their backlog and can actively engage with adjusting the scope of their project to meet their budget
  3. The risk on project is balanced between client and agency: the client takes ownership for delivering a functioning product within their points budget; the agency takes ownership for delivering each fixed price component.
  4. It rewards the development team for being efficient but not for cutting corners
  5. It necessitates regular, involved sign-offs from product owners and facilitates a more collaborative environment
  6. It makes it easier to quickly switch directions within a project based on user feedback – a client can adapt and pivot when they’re provided with feedback from real users and are empowered to prioritise user feedback over new features if they wish.

Ultimately, working in this method drives adherence by the agency to an agile working methodology. You simply have to meet your definition of ‘done’ or you won’t get paid.

There are problems. One of the fundamentals of agile is Goodhart’s Law – When a measure becomes a target, it ceases to be a good measure. You can make a pretty strong case that this methodology falls foul of that…however, I feel this relates more to velocity rather than story point though I do accept the criticism.


Agile ‘laws’


Those in the #noestimates camp might also argue that this still doesn’t solve the overall problem of estimates being inaccurate and unnecessary. However, I think this model can work around such objections, especially in an agency environment. There are a number of things you can do to help do this

  1. Work closely with clients, begin educating them on your estimating process and encourage them and expect them to challenge your estimates. They are  a key point of triangulation in this.
  2. Understand that your estimates will still be inaccurate but over time, a greater project understanding and clear metrics can allow you and the client to make adjustments in order to rebalance any inequality. Invest in consistent and robust estimation techniques and let the numbers provide accuracy over time.
  3. We also have found it a necessity to have a fixed-price or T&M period before the project starts. this covers all the workshopping, server set-up, user story writing etc. The tasks are familiar so we can estimate them fairly accurately but investing in this phase allows us to have relative confidence in setting the price per point for the upcoming project.

Other agencies have tried this model or adaption of it and seem to have also had reasonable success. It’s interesting that I hadn’t heard of this model before but we organically evolved into it. It was only after trying it and doing further research that realised than many other had been using this model for a while:

Kurt Haeusler gave a talk on this subject in which he has far more time to expand on these themes and does a far better job than I could. It’s a really interesting video for a number of reasons and I recommend you give it a watch if you can.

Finally, If you what my slides from the event, they are available here:

Or as a google doc:

Please drop me a line if you have any questions or are interested in moving to this model and want some advice. 



DPM:UK 2015 Are you going?

Last year I was lucky enough to attend DPM:UK 2014. It was lots of fun to get out of Oxford and see some of Manchester again, but far greater than this was the inspiring opportunity to connect with Digital PMs from a wide range of backgrounds.


Some highlights from last year…I’m in one of these photos.

I found DPM:UK to be a really friendly event, I met experienced PMs and some PMs who were very new to the industry or had just started trying to move into it. It was great to be able to pass on some advice about courses and qualifications to people in this position. I also learned a lot about the thriving digital scene in Manchester – it’s so easy to get drawn into your own regional bubble that you can forget about the innovative and inspiring work happening in cities like Manchester, Bristol, Brighton. Even outside these ‘hubs’ I met people from Glasgow, Halifax and from small regional towns all working on really high-end and mind-blowing digital projects.

Overall the conference for me was a big affirmation that I’m in a really exciting, growing industry and not only that – Digital PMs are in demand. There were a huge number of job opportunities being talked about or put up on the message board. Even though I’m totally happy with the fabulous agency I work for – It’s still a bit of a buzz to know that lots of companies are actively seeking people with the same skill-sets as you.

Aside from the connections and the general buzz of the event, there were obviously the great talks. All of the speakers were really excellent and the event ran really smoothly. I could find numerous positive things to say about every talk but in the interests of brevity I’ll just mention the key ones that had a really long lasting impact on me:

  • Mark Coster gave a talk about agile that really changed my perception of the level an agile team could work at. I had been struggling with a massive ball-ache (sorry there is no other adjective for it) of a data migration at the time. What was interesting is that Mark had clearly had  very similar problems in one of his projects but had probably controlled it much better. What I learned from his talk was that by remaining transparent and offering clients clear information and regularly updated projections –  you allow them the choice to abandon or change key elements of a project. At the time, I’d been so focussed on trying to ‘deliver what the client wanted’ that I hadn’t been doing enough to empower the client the opportunity to change course. It was also nice to know that I wasn’t alone in feeling the pain of data migrations and no matter how experienced you become as a Digital PM – you will always face intensely challenging problems. You can’t ever stop this happening but you can work on the way you react to such challenges.
  • Sam Barnes as ever was excellent and I’m glad he will be returning in 2015. His talk led me to speak to our AMs about the way we present our proposals but it also reinforced one of my key beliefs which is: despite Digital PM being a very technical sounding job – 90% of it isn’t technical…It’s all about empathy. If you can be empathic with your client and your team and really work hard to understand what they need and want, then the job will be so much easier. Miscommunications, divergent expectations, lack of support and a breakdown in teamwork are the things that blow projects out the water…not anything to do with an individual’s technical ability.
  • Paul Boag also left us with a really inspiring end to the day. His talk was wide ranging but really hit home that we are working in an exciting time. It isn’t a cliche to say that old models and traditional ways of working are crumbling. Once you let go of the safety net that tells you ‘this is what a job is’ or ‘this is the way you build things’ it’s actually a liberating experience to realise that our job is not only to create and build digital things; it’s to create and build the ways in which we build digital things.
  • Finally, Rob Borely from Dootrix was great. They are doing some really interesting things at Dootrix. What certainly inspired me was they way they making agile work in an agency environment. It’s so easy to adopt an attitude of ‘the customer is always right’ and bend the rules of agile to suit your client because they can’t make a sprint planning meeting or they want to you to commit to a key date when they haven’t yet given you the information you need. Dootrix seemed to take a sensibly firm line with their clients because they knew that eroding the process would result in far inferior products. It inspired me to spend more time on educating product owners and less time on trying to do their work for them. I also really liked that they had non-work sprint breaks in order for the team to be able rejuvenate and thus focus more during active sprints…It’s something I’ve started trying on a current project and am indebted to this talk for giving me the courage to do so.

I could write paragraphs and paragraphs more about every other speaker, but the more important message is that if you are a digital PM/AM or someone who has to deal with any part of managing digital projects then you should get yourself to Manchester on January 29th.

Tickets are still available:

What’s more I’m sincerely honored to say that I will have a chance to speak at this year’s event.  I feel very privileged to be on such a great bill of speakers and slightly nervous if I’m honest too. However, I do feel I have something of genuine interest to speak about and can only hope I’ll be half as inspiring as some of the great speakers last year.

Hope to see lots of you there. There’s a good crowd of us coming from Oxford, so if you want to meet up, just reply to this blog post or tweet us @DOxPm.

Is Scrum valuable to the team?

It is essential for every team who strive to be agile that the daily scrum happens. Often this routine exercise can become stagnant and mundane with the same three questions explored for each team member:


What did you do yesterday?

What are you doing today?

Are you  blocked i.e. need assistance from any of the team to complete your tasks today?


Scrum should ideally be about sharing useful information with each other and the team should be pumped for the day! How can we expect a client to be excited about 10 minutes of the same old if we are not striving to make scrum standup fun and interesting? The team should not always resort to the standard way of doing scrum, scrum is a great chance for clients to engage with the entire team. Be involved in the conversation.


Something one of our project managers here at WO organised  whilst he was away on holiday was a “Scrum Dine with Me” challenge. Each member of the team took it in turn to be the scrum master and they were marked out of 5 and the winner was be revealed on the last day of the week. Getting creative really encouraged the team to think outside the box and gel more, therefore becoming a more productive team. Some examples include choosing temporary tattoos to describe your day and to justify why you chose that one, another fantastic idea was a scrum cake.

Scrumetune cake

Figure 1 – Scrumtune cake from the Head Of Design’s day of Scrum Master

temporary tattoos

Figure 2 – Fellow designer Sarah Plant’s Scrum Master day with temporary tattoos

Where does the client come into this? Not every client can be present for scrum, we have clients all over the country, the world even. The answer to this is virtual scrum, phone in using a VOIP system to get their input, but is it as good as face to face standup? We have a client who comes in very regularly and as a consequence the team have an awesome working relationship.

 It is difficult to have the Product Owner come in and scrum as they often have an everyday job as well as being there to answer the teams questions. Virtual scrum removes the standup, involvement and fast paced feel of the scrum session.
Is scrum valuable to the client? Yes, but it has to start with being valuable to the team. Make it different, mix it up a bit and keep everyone on their toes. Make it exciting, help everyone play their part in driving the success of a sprint.