Accountability vs Responsibility for Getting Things Done!

So how do you get things done when you don't own the resources.. eg in a matrix organisation?

Some think that assigning accountability will resolve the problem.. 

From my perspective, accountability is important, but responsibility is the bottleneck... 

Example of responsibility is the developer who has 100 competing priorities vs a project team lead who has the accountability for only a few workstreams and may not be part of the permanent team.

This happens frequently when projects/priorities are viewed in isolation.  Steps to ensure that staff are fully booked (eg charged back to the business) usually result in key staff working overtime because the peaks and troughs of work are not smoothed - rather they create a tsunami and quality suffers (and rework/remediation is added to the forward work load). 

So back to getting the people responsible to complete on time with the quality which ensures the very minimum of rework.... and let's start at the beginning of the project because I think that different strategies are needed to cope with different types of people.

Mobilisation - in this phase, it's important to deal with ambiguities, dependencies and basically put together a puzzle of parts – some interlocking and others drifting in a sea of time (eg it could be done in a number of different  “time zones”…  Here it is important to a) get individual SME (subject matter expert) input; then b) develop a strawman and the c) put the SMEs together to ratify the programme.  Outputs are refined Business Case, Schedule, Resource plans, Design Decisions, PID, etc.  So the issue here is how to motivate SMEs – where stressing the value of their input to the programme*  is probably the best way to get participation. *Even better if the programme is a strategic necessity.

Design phase – in this phase the bottlenecks are usually complete Business Requirements, getting those requirements signed-off, completing Functional Requirements and then providing traceability between these two inputs and the test cases which will be used to ensure that the requirements have been delivered.  Getting complete business requirements is always problematic – particularly when stakeholders have different ideas.  The best mechanism I’ve found is to use “brown paper” exercises to highlight current pain points and then brainstorm how to remove/reduce them – and get these signed by everyone in the session.  Having their names as the people responsible for identifying the problems and the solution should be viewed as a career enhancing activity.  Then comes the getting sign off from stakeholders (some of which would not have participated)… here comes the stick – eg the delays in getting sign off WILL delay implementation as the development window will be squeezed or shut out altogether (additional costs in the form of contract staff not being utilised or needed many additional staff to complete on time will impact the Business Case). 

Development phase – here’s where coffee/doughnuts and anything to improve the working environment comes into play along with weekly morning “prayers”/pep talks rather than status meetings – If possible use pictures to depict progress and forward targets.  Knock down the bottle necks and knobble the competing priorities by agreeing those separately in a manner which does not distract the development team from being productive… Kind of like agreeing to not argue in front of the children.  And to do this, it takes artful negotiation and a bit of give and take.

Well that’s enough to get started.. no doubt more will spring to mind.

#pm #pmot