Consider this. Why on earth would you have someone managing a project who can’t control when the work gets done? And, why on earth would you have a team of people doing the work who don’t communicate directly with the client? Developers are, in most cases, the best project managers. They understand inherently what’s going on in a project. They’re coding it. You can trust they’ll be truthful about when work will get finished. They’re coding it. They can deliver terse, no-bullshit statuses to a client on a project. They’re coding it.
Yet, for some god-unknown reason, this highly skilled, highly paid team of programmers has been taken out of the direct line of communication with clients. And the project managers, bless their Gantt-chart-hearts, are left to bridge the gap. And, speaking on their behalf, they have better things to be doing.
So, fire your project managers. Better yet, give the m another job. The job of projects manager. Note the use of the plural. There’s a whole lot of horizontal organization which needs to happen across the business’ portfolio of applications. Change orders, daily stand-ups, staffing, estimates, briefs, calendar negotiation, and so on. This is work a clear-headed organizer excels at. And a note to developers: it’s not easy work and should pay very well.
Now, give that silo-minded group of programmers the reigns to manage the day-to-day activities of the project and the responsibility to work directly with the clients. Specification, request negotiation, issue resolution, and so on. You see, programmers are pressed for time, short on specification, and long on endless lists of additional requests, tweaks, and sprints. So, you can bet they’ll make judicious use of the client’s time.
Programmers are pressed for time, short on specification, and long on an endless list of additional requests, tweaks, and sprints. So, you can bet they’ll make judicious use of the client’s time.
Also. Give ’em Basecamp and an issue tracker and make sure the clients use it. Yes, they need to be on the hook to communicate clearly and regularly with the clients. If they’re doing daily stand ups, then invite the client to listen in. And, of course, they need to ‘socialize’ all fundamental decision making. Ask them though if they’d prefer to do this because they’d be better at it (stroke their ego), and they’ll probably be happy to do it.
My hunch is that your project manager won’t mind being excused from the duty of ‘mouthpiece of ye heralded programmers’. And the programmers won’t mind speaking the truth to the client. If you’re afraid of developers and clients sharing truths, then this message will self-destruct in 20 seconds. Run.
Things to think about
Designate a Developer Lead
Every undertaking needs an owner on the technical team. Call it the Developer Lead. Above being responsible for a lion’s share of the programming and delegating tasks to others, they’re the mouthpiece of the entire production team, responsible for direct communications with the client regarding specifications, schedules, and build notes. They are the truth. Not a light responsibility.
The project manager services the Developer Lead
The traditional project manager services the Developer Lead by noting decisions, creating documentation, and performing any other operational duty the team needs to stay focused. They’re just as much a part of owning an application and determining it’s fate, but again, they’re not the go-between for clients and developers. And account executives? Not sure what to do with them.
I’ll also add that the project managers start their work in advance of the development team. There’s plenty of up front prep work to take care of in advance of a development team rolling up their sleeves.
Define a convention for communications
Style doesn’t matter, but grammar does. Most people take the short cut with their writing styles online (read: pm’s and devr’s). Clean it up. With just a bit of enforcement, the entire team can be taught to take and extra 30 seconds to add a salutation and a closing in each email, issue, or basecamp message. For lengthier communications like build notes, create a template. In short, formalize the communication by making a convention of it. This goes a long way towards winning social trust between production and client teams. Plus, it’s simple.
Above all, instill accountability. When the developer team hears directly from the client’s mouth that there’s a problem, they take it at face value and aren’t given the chance to blame poor communication on the account team. Likewise, the client will learn a bit of empathy for the development team, which provides good incentive to prioritize. Win/win.