The need for speed – why Project duration is “only the symptom”
In the last few years I had the privilege of working with many delivery and IT organizations, most of them looking for ways to shorten projects, reduce cost and become nimble and fast. Some are smaller, some are bigger, but the above is something they all have in common.
Working with all levels in the organization, from developers to management, it was sometimes interesting to see the gap between the perception of the management, to the real effectiveness of their teams. Whether it is bureaucracy, mediator layers, intense conflicts or inefficient processes, things sometimes get lost in translation, and while the management is struggling to understand why the desired result is not achieved, the teams are losing more and more of their empowerment and leeway.
Now, as someone who led 100’s of people in delivery projects, I am not dismissing control and measurements, not at all, but I find that there are common mistakes and sometimes blindness to the importance of balancing control with empowerment and leeway. If you hear often comments like “why do I need to chase people for anything to happen?” or “I have to work hours on redundant forms and reporting”, those suggest that people in your organization don’t feel empowered, and make no mistake, it directly reflects on all those “goodies” you are looking for.
So how can you move the needle?
Few do’s and don’ts that I find crucial as a start:
Do:
- Reduce number of “gate keepers” – For short term they increase control, for long term the damage is big. It often creates significant amount of waste and for sure decreases motivation and fighting spirit of your key people. Reduce mediator levels - Reporting should come from managers directly. They should be trained and educated for the importance of basic reporting.
- Ensure frequent interactions with business at all levels of the organization – developers, especially those work in a matrix, do not meet their end customer enough and with time, they lose business orientation and focus and become totally disconnected from the goals. To prevent this from happening, frequent exposure to the business customer (in whatever way – conference, demo, town hall) must be obtained.
- Encourage an environment of learning the creativity - implementation of new ideas, not necessarily significant changes, but small, frequent changes. learning forums, training, lectures, workshops, town halls, online webinars, and any other form of development framework for people, keeps them open and self-confident. This self-confidence is crucial for your project’s success.
- Optimize conflict level. While inherited internal conflict and competition are positive to some degree, when they become too intense it is totally destructive and directly impact efficiency. Conflict level can be optimized in different ways like constant, consistence communication, measurements alignment, increasing trust between groups, and more.
- Invest in junior and mid-level managers training – As talented as they may be, junior managers often struggle in a matrix and remote management organization. Once they get the tools to succeed, much less frustration and much better expectation alignment will be achieved
Don’t:
- Don’t build matrix in a matrix – the farther the “end developer” from the project lead (as far as matrix layers and hierarchy layers), the less nimble you will be
- Don’t allow needless escalations. Send teams to resolve the issues between them.
- Don’t allow negative communication (including mails), Negative communication is a clear indication of high level of frustration in the organization which must be addressed, but at the same time and until addressing the root cause, effort should be directed to stop offending communication as it is extremely destructive.
Measure:
- Encourage matrix efficiency by measuring time for staffing (a new project) and team stability
- Ensure customer focus by measuring - Cycle length to feedback/customer feedback frequency
- Encourage value focus and openness to change by measuring business value, but at the same time continue to measure scope instability. Changes to scope before development should mostly be OK (based on business prioritization), but changes to scope after development should be measured because when frequent, they are likely to impact timeline. Then it is a joint business & development decision how to manage it.
At the end, it is all part of the change we need to go through, from a traditional hierarchical organization to a simpler, leaner, collaborative one, that speaks and acts the same language, which is a clear and consistence language.
And while this is a long journey and it has to start somewhere, the holistic view is what’s going to make the real difference. After all, projects don’t stand by themselves, they are a representation of everything that is superior or inferior in the organization, everything that is superior or inferior in …us.
And, for those interested in more – a highly recommended related article:
