Michael Dlugosch works as a Senior Consultant at Kwantic Oy, a Web Analytics startup company in Helsinki/Finland. Follow Michael on Twitter
In Part 1 and Part 2 of this series, Michael talked about the first four deadly sins of digital project management. In this third instalment, he focuses on dealing with delays in client feedback and controlling the scope of a project through thorough digital project documentation – Anger and Covetousness.
5. Anger – “Dear client, as you failed to respond to my earlier emails…”
I come across many Digital Project Managers who seem to personally suffer from the client’s inability to give feedback in good time. Though this is an annoying fact, in some situations it has to be attributed to a Digital Project Manager’s inability to cater for this situation – beforehand, or as it emerges.
Trust me, even if you happen to inherit a digital project where you are dealing with non-responsive client, not all is lost, yet. Countless intelligent people have devised Digital Project Management documentation frameworks which would anticipate this situation, and prevent the worst case from happening.
However, I haven’t seen many digital projects where all of this ideal world project documentation was in a grade A condition from the start (not even the ones I have started from scratch!), but then again, I’ve never worked with clients who wouldn’t have accepted a mode shift along the way, either.
But, if you have ever been forced to wait for client approval beyond the launch deadline you surely were caught between a rock and a hard place. As soon as this happens once, you are fully entitled to ask for a change in the mode of operation. In my experience, digital projects tend to suffer from bottlenecks which are related to the allocation of time within the client’s organisation rather than your own.
Benefits of project communication logging
I had a client once who was managing a time-critical launch bound to an event where he had to participate in person and where he couldn’t be reached by email or phone for the whole afternoon while material was missing from God-knows-where.
We decided to go live with non-approved interim content. The client cried “Betrayal!” and refused to pay the bill.
I said “OK!” and stated I would simply send the project log (where all digital project communication was recorded) via my boss to his boss to document the issue on behalf of our project team.
“You’re keeping a project log?” he said, with an amount of fear.
I replied, “Listen – do you really think that we, as a digital project delivery organisation, wouldn’t organise and document our own digital project delivery process? This is what we do for a living!”
Whether this project log exists or not is up for debate, but my advice is only ever be bitchy if you have evidence!
However, it is somewhat ironic how rarely the principles of digital project management are applied to the digital project management process itself. Managing the digital project management process is one of the most worthwhile tasks – and one of the most essential for complete confidence and stability on-going.
Digital project delivery definition
In order to minimise situations like the above from ever happening, what I try to do from the start with any digital project I am involved in, and if I fail, do as soon as I find the time or as the need emerges is:
- I re-negotiate the prerequisites of delivery. Any digital project which I have ever seen is based on assumptions e.g. “if we use framework XYZ, we’ll be fine” and “we’ll get all the materials in time”, and not forgetting the assumptions formulated out of pure madness like “we can do last changes on the materials in the two hours before we go live with it”
- Whenever I read a digital project briefing, or an RFP, I take a piece of paper and note down under which circumstances the stuff I read makes a reasonable request. And particularly, what are the likely points of failure?
As a result, my latest digital projects had quite impressive sections in the Management Summary part of the digital project agreement document.
One is labelled Assumptions and the other is labelled Prerequisites and they match the headlines on my auxiliary notes. One listing general delivery-related things and the other is listing items with regard to the project delivery schedule.
The first section states “Tool access is granted by the client” and the second states the deadline associated with it “Tool access is granted until 16.09.” which is exactly the start date for a project phase relying on the availability of certain things.
You’ll get the point here, I’m sure.
Needless to say that I, in some cases, failed to hand in the digital project agreement document on time due to the extensive additions to the project agreement which was originally drafted. For times such as these it always becomes handy to formulate the essential “Three sentences why this document is late” for yourself, and for your Account Manager who will no doubt steal the formulated and re-usable excuse.
In one case the client went as far as to verbally convey their suspicion that I might be “not quite up to the task, maybe ‘incompetent’, or just a little inexperienced?” Thanks to the preparation, my Account Manager was prepared to extinguish this fire with a smile despite the fact they had asked for a simple task equivalent to order the following from your favourite bartender:
“One beer, but the foam on the bottom of the glass please!” – They got it and we got paid for it.
6. Covetousness – “Sure. This feature will cost you €10k”
As you may have guessed from what you’ve read before in this series or from experience, an unreasonable demand doesn’t get any better, regardless of how often you repeat it.
The key to make people pay for the things they are desperately asking for, which is beyond the agreed scope, is to comprehensively document the interdependencies between the parts of the puzzle for all to see from day one.
Working with a detailed Work Breakdown Structure (WBS) document makes this a much easier task. Everyone will have their own take on creating a WBS, but this is mine step-by-step:
- Transfer the different high-level stages of the project to pieces of paper – one phase goes on one piece of paper – or put it in an Excel file, if you want
- Think about the competency contributions you will need for each of the phases and how they relate e.g. What do you need to get done by Web Designers in each phase? Is there anything that Software Architects or Web Developers can contribute, prepare, or review in a particular early phase of the project?
- Add according lines to your paper, or add empty lines to your Excel. If the phases are in column A, put the tasks to be performed by particular competencies to column B. In both cases add marks to who is contributing in a separate column
- Put all deliverables that you need as input for any of the phases in the upper left corner of every sheet. Making sure to note down which competency is contributing to which item in a separate column in the same place
- Finally, try to envisage how the different contributions fall together into separate tasks. A Web Designer surely has to:
- Select the images for the web site
- Manipulate the images
- Finish them for web usage with sharpening, compression and naming them according to the defined naming conventions
- Think about who uploads these images to the web site repository: the Web Developer? A Content Editor? The Project Manager? The Holy Ghost?
- You will find both new tasks which are not covered in the basic project agreement new assignments which haven’t been thought of yet
What you will end up with, is complete knowledge you can present to your team, superiors and client on what action sequences need to happen in order to deliver e.g. There no point in uploading images which haven’t been selected and/or made ready for web usage, right? The dependency is created.
In the end, add the outcome of this examination to your sheets (preferably with a different colour).
Deliverables are marked with a right arrow (deliverable_X -> phase_Y), inputs to further phases are marked with a similar arrow on their left (phase_Y->input_X). Make sure every deliverable of one phase matches an input to another phase. Assign numbers with high-level phases get a single digit number “1”, subsequent packages get “1.1”; particular competence contributions get “1.1.1” and so on…
And there you have it, a WBS document, matching both the output dimension of phase X and the input dimension for phase Y. Split by competencies, bound to digital project phases and reflecting the actual deeds and work packages for everyone to see and track throughout the project’s lifecycle. Splendid!
In the final part of this brilliant series, Part 4, Michael talks about Sloth, the last of the Digital Project Management deadly sins. It deals specifically with the constant struggle Digital Project Managers have when trying to allocate resource to their projects only to discover there is none available.
Leave a Comment