How to delegate deliverables successfully within an agile world? |…

I am still having trouble delegating

You see, I am the kind of person that likes to understand how things are done and due to my curiosity, I oftentimes have an opinion on everything. This, coupled with a “yes I can” approach makes me want to have things done the way I would do them. For a long time I was a “one man show” professionnally speaking, and still consider myself something of a generalist. However, working on team projects, a manager quickly realizes that delegation is key to success. Few grand undertakings are the work of a sole individual.

What I would like to talk about today is the way one can successfully delegate deliverables within a BI project context. More to the point, agility enables interesting delegation methods and strategies that I think merit reflexion.

Factors in assessing task delegation

When I think about delegating, I consider the following elements of the task :

Criticality: What is the impact to the project scope if the task is not done correctly;
Complexity: What is the level of expertise required to accomplish the task;
Time sensitivity: Is that deliverable required early on in the project?

Delegation to the team leads

In theory a PM must not always have to know the ins and outs of the project’s realisation. This is true of the more “administrative” project managers. However, I find that in Business Intelligence, stakeholders, and PMO’s require their PM’s to be knowledgeable in the specifics of the project. They require functional project managers; Individuals that can speak too, and about, the project with their clients. This helps build trust and a rapport with the business that is an essential component of a Business Intelligence project’s long term success.

The team leads are senior resources on the project team. They are usually the data architects, solution architects, data modelers, lead designer, lead developper or the business analyst. To these individuals more complex elements of the solution should be delegated.

Delegation to those resources should be on the critical aspects of the project. They are to be responsible for analyzing and designing the solution. Team leads should also be encouraged to delegate their tasks down.

Managing the Communication Risk

Care must be done when delegating tasks that will result in communication with the stakeholders. The PM must maintain strong inter communication with the in order to have the latest news from their discussion with the stakeholders. The risk of not doing so will be confusion on the part of the client “but your guys told me the opposite yesterday!” and loss of rythm. Ideally, only team leads communicate with the stakeholders, and as much as possible with the PM or BA in tow. More junior resources would normally communicate with the SME’s (Subject Matter Experts). Again, if few project resources communicate with the major stakeholders, the less risk of miscommunication and misalignment.

Delegation based on time-based value

Agile projects need to deliver value every two weeks. This means that some project elements will have to be in place early. Those elements are ill suited for the more inexperienced resources, which might not have the time to handle the responsibility. I would recommed elements that are less critical, or better, elements that do not need to deliver value immediately.

The slower the velocity required to deliver, the more the direct can have the opportunity to learn and have its responsibilities increase incrementally throughout. This makes a lot of project tasks great for more inexperienced members of the team :

Knowledge base management
Coding standards
Testing
Data entry templates standards
Data profiling
Promotion activities
Customer testing support

Delegation of “processes” is a great way to enable more junior resources and have them have an impact on the project. It builds confidence and lets them speak out to more experienced resources in a position of leadership.

Project/Sprint/Issue delegation

Some delegation elements, like the solution architecture, live throughout the project’s life. Others, like adressing a bug, can be delegated to a resource for resolution within the sprint. Again, delegate based on the criticality, complexity and time sensitivity.

Blind delegation

In the heat of the moment, many resources will jump to the occasion and say “yes” too quickly to delegation. An experienced manager will need to assess the ability of the direct to take the delegation. Validate the ability of the individual to be able to deliver. Ask in a private conversation and if in doubt challenge the direct. It is better to know early. Directs must know that they can say “no” to delegation if they think it adds risk to the project.

Delegation must be carefully scoped. As always the keys points are :

Be realistic; Delegate elements that the resource can accomplish. Do not over delegate;
Manager risk; The higher the impact of failure, the more experienced the resource delegated to needs to be;
Enable and Empower; Delegate authority, but the end responsability is still on your shoulders;
Set Control; set control points to monitor the direct and adress issues quickly and efficiently;
Leave breathing space; Don’t overshadow the direct and stiffle his creativity in managing his delegated tasks;
Create expertise; Failure will happen, but lessons are learned and failsafe processes put in place;
Foster trust; The direct must feel your support, and not your judgment in your communications.

Remember, project management is like a waging a battle. A good general delegates down as much as possible to his platoon leaders, but he is ultimately responsible for the result of the war!

In order words, delegate down, but responsibility always floats up!

How to delegate deliverables successfully within an agile world?