The answer is, yes.
Rather than technical skills or experience, a non-technical digital project manager can rely on a different skill set – the ‘human skill set’.
To be successful, the PM will need to be in as close contact with the technical work teams as possible. This is easier for the smaller organisations or in-house development, but the principle can apply to larger scale or external development work.
It’s not always easy going for a non-tech PM, but if you apply these ‘human skills’ and take notice of the way your technical teams are working and delivering, this is often a good approach. Even without knowing the technical intricacies of the work being produced, you will get a good indication that your teams are capable of producing quality work if you pay attention to the details.
- Are they doing over time?
- Do they appear overly stressed?
- Are smaller things continually being delivered off-specification?
- Is their team manager or senior person accessible to them?
And if you yourself are unsure or a little confused, you can bet that the teams are too.
One thing I have learned is that software developers often take the approach of “it’s easier if I stay back late and re-code this crappy work myself” or “I could add some real value if I build this extra function”…! These guys and girls are heroes, they are making you look good and they are saving your bacon, right? Well in truth, they are definitely heroes, but potentially they are doing more harm than good from a project management point of view.
Signs like this are red flags that your project may be about to veer off track, so take notice and stay in touch with the tech teams as much as you can.
Potentially, bigger issues are being covered up and you are not being told soon enough or they are concentrating on functionality that would be totally cool to have, but not what was paid for.
Take note, this kind of thing happens often and it always happens for a reason.
- The work was spec’d incorrectly
- There has been a mis-communication
- The developers weren’t involved in the planning and accordingly the spec is full of holes
- On larger projects, maybe the separate development teams do not understand the cross over in their work or worse, their own delivery requirements or interdependencies
So while there is significant benefit in understanding the context of the work to be produced, so you yourself can mitigate any holes or mis-communication up front, it’s just as important to understand people.
So to be successful as a non-technical PM in a technical project, know your people and get to know the status of the work being produced and know what your developers are actually doing. Be prepared to ask them to show you which particular requirement they are working on and/or raise a flag if your gut tells you too.
We all have that little voice in our heads and it is a valuable thing. Listen to it.