Introducing agility into traditional systems development processes is never easy. Firstly, you have got to want to change. Secondly, you need to have a vision of what to change to. Finally, you need the tenacity to forge ahead in the face of stiff resistance. It is usually the third that is the most difficult journey to undertake. The hardest part of the journey is during the transition wherein you show how to bring agility into executing projects. You are walking the fine line between traditional methodology and incrementally introducing change.
You’ve got more capacity than you think
Managing a business today means leveraging your existing capability to maximize throughput. Why am I focusing on throughput? If you think about your organizational value stream, you only make money (or realize revenue) when you deliver a product or a service to your customer. Having a large volume of work within your organizational pipe while not delivering anything means your investments are tied up with work-in-progress inventory. The more work-in-progress inventory you have the more investments are needed. How are you going to fund this investment? The faster your deliver, the faster you realize revenue. Hence, the focus on throughput.
Predict project failure using cumulative flow diagrams
One of the biggest challenges I face as a project manager is the ability to predict the project or program’s future. What impact would the change request have on the project? Are we going fast enough to meet the program deadlines? Are the team’s estimates good enough? Assuming the team will meet most of its estimates, what can we do to go faster? Why do I need to wait for 5 months before I can touch and feel the product? These are just a few of the questions that needed answering throughout the project lifecycle. Critical Chain changed all that. I was, at last, able to predict project failure long before projects got off the rails
Combining Critical Chain and Kanban to improve capacity
It has been close to two years since I embarked on the path of using Kanban within our software engineering teams and a year since I first piloted critical chain project management. Both concepts have benefited my projects. Why adopt the two simultaneously? They address two different needs: one looks into the future to determine if the project will be on time and within budget while the other highlights bottlenecks as they arise.
How Kanban resolves the resource manager and project manager’s dilemma
Project managers are in a constant tug-of-war amongst themselves and the resource managers for people. The goal of the project manager is to complete the project on time, on budget and deliver to the scope. The goal of the resource manager is to ensure the maximum utilization of the people who report to him/her.
Making Kanban work in matrix organizations
For those of us working in matrix organizations, this is reality. We have to constantly juggle between projects, maintenance and operational work. It takes forever for the work to get done. One who screams the loudest always appears to get attention. Work is typically assigned to teams based on schedules and forecasts. The nail in the coffin is that the estimates are treated as deterministic when they are, in fact, probabilistic; i.e. estimates turn into commitment as soon as it gets entered into the Gantt (or a roadmap)