Tag: project management


Transforming from waterfall to agile

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.


How to implement critical chain project management across the enterprise

I have frequently been asked – how would you actually implement Critical Chain project management? But before I get to that, why would you want to implement critical chain? If you work in an organization that follows traditional project management practices, it is likely that critical chain project management may appeal to your PMO. You […]


Flow in traditional project management process

Traditional project management resembles a PUSH system. A push system is where tasks are planned and scheduled. The time between requirements definition and delivery is so long that things change. Adding to the chaos is estimating, large batch size and requirement for high people utilization (in matrix organizations). Estimates are just that – Guesses. Building a schedule and a forecast based on guesses is a recipe for disaster. Yet this practice is condoned and encouraged.


Portfolio management using Kanban and Critical Chain

if you have been following my blog or have been at my presentations over the last few months, you know that I see the application Theory of Constraint concepts as critical to helping the organization achieve its stated goals. A number of folks are of the opinion that one does not need Critical Chain project management at all – adoption of Kanban is enough. I differ.


Kanban saves the day

I was brought in to deliver a project on-time with less than 2 months remaining. While the project scope and deliverables were clear, getting to the solution was not.

R&D was required to get some of the features delivered and that was expected to take up a significant amount of time. The team was cross functional and dispersed – from vendors to in-house application development folks to network and server infrastructure folks within Canada and the USA. There was no time for detailed planning. The deadline was non-negotiable and the project had to be delivered by the due date.

It appeared that delivering on time was a tall order and the team was wondering how in the world they would get it all done.

Back To Top