I am not a Digital Project Manager, but I am extremely interested in running an efficient and effective process.
Right now, I am feeling there is a big gap in the review process. I’m looking for confirmation on how a digital project manager should be involved during our QA and the client approval stages.
I work for an agency that produces client marketing sites. There is heavy involvement from DPMs during the design, architecture and content phases – but as projects move into the development phase their involvement starts to decrease.
When the site is done being developed, it goes through an internal review and QA process where the DPMs are hands-off and expect other team members to manage the backlog and prioritization.
Once the internal team wraps up the issues found, the DPM hands the site off to our client for their review and approval. As the client logs issues, the project manager is again hands off, expecting other members of the team to triage, prioritize and fix. The only way the DPM gets involved at this stage is if they are requested to look into an issue.
This feels wrong to me. I get worried about someone other than the DPM owning this aspect of the project due to the project manager loosing insight into the project: the level of effort, scope creep, what items take priority, understanding overall quality of the initial deliverable to the client.
Big picture I think they are loosing insight into trends: what mistakes are we making every project, how many client issues are getting logged, etc.
Am I wrong? I’m looking to get an understanding of the expectations of the DPM. Can you all help?
QA please and thank you!
Man, I’ve been re-reading this question over a big glass of wine and just revisiting all the messy QA experiences of my life.
It’s a messy time in any project. It’s a time where things blow up. Things rise from the ashes. The internal team hits their limits and clients get frustrated. Weirdly enough it’s one of my favorite times. [A typical DPM reaction during QA can be found here.]
Every agency/company/studio/business/etc. is different.
In some cases I’ve been the QA engineer by default [not ideal] and in others – we outsourced QA. Regardless, it’s something that is always performed. It’s always done with attention to detail. It’s typically the DPM that carries the blame if any issues arise. You can’t fake solid QA.
What’s important to identify from the outset is browser/device list before starting on the project, ensuring roles are defined in terms of bug categories – who’s responsible for assigning and validating bugs, and who’s wrangling the client with any scope creep.
QA is a symphony. Not a band.
Think of me wagging my pointer fingers left and right like a maestro as I write this. The role of a DPM in QA the maestro. It’s top down leadership. They ensure that issues are prioritized properly, that all bugs logged can be replicated based upon the instruction of the QA Engineer, that the browser/device list and test cases.
Typically I would have all QA Engineers assign all reported bugs to me so that I could evaluate and assign to team members accordingly. I am the gatekeeper. In certain cases this means I had to request more info or mark as wont fix. The thing here – is that it’s important that DPM’s have a solid pulse on project health and performance from the very start to the very end. But you know this – so here’s how I’d get your DPM to know this.
Go do some Front Stabbing.
I don’t know what your role is – but you’re on to something here and the best thing is to do some front-stabbing.
Belskey says in his article: “Confrontation tends to be most needed when it is most uncomfortable.”
So, it’s up to you to say something in a kind and empathetic way. Perhaps over a coffee [or Slack even] ask, “Hay, I would really appreciate it if you could help prioritize the incoming issues from the client. There are so many and I could really use your help to ensure I’m focusing on the right tasks”.
Developers have patronized me into the ground and will continue until the end of time. Perhaps your DPMs are they’re afraid to speak up? To own this process? Give them a gentle nudge to step up and own this.
In conclusion, step up and help your DPMs own and wrangle the QA process moving forward. You’re right in that something is amiss currently in the workflow.
I’m wising you the best of luck not only for improving QA, but ultimately the health and success of your projects.
Our friend and supporter: