In the current era of economic uncertainty, there is no dearth of gloom and doom news. Europe, Asia, the Americas all have fallen like dominoes to the credit crisis of 2008. Austerity measures have been put in place in a number of countries. Economies are spiraling downward. There is talk of the breakup of the Eurozone with Greece being the first causality. People are tired; tired of losing jobs; tired of having limited opportunities for growth. Companies are downsizing and people are asked to do more with less. But doing more with less does not have to be all about burning the midnight oil. Managing your business in this new era means bring smart about how you run it. If you are always complaining that you need more people, think again. You may have more capacity than you think. (continue reading…)
The journey from “Sure” to “No” to “Not now”
Recently I was invited to a meeting where the discussion was how to implement Kanban within the team. During the course of the conversation I said, “… we need to start saying “No” more often…” A colleague smiled, “Coming from you, that’s quite a change”
I consider customers to be the greatest assets an organization can have and have always said “Sure” to requests. I try to exceed expectations and I tend to encourage people I work with to do the same. However, as I began working with the Kanban, frequently, I find myself asking questions like, “Are we sure this feature is value add? What benefits have you identified? How would you quantify the investment? etc.” We all have very limited resources and people time. So I probe deeper to understand if the undertaking provides significant benefit. This approach also helps the customer reiterate the feature benefit. A side benefit is that this helps limit work-in-progress at the program and portfolio level. (continue reading…)
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 can most likely follow the your existing BDUF (Big Design Up Front) process and still implement Critical Chain. The biggest benefit of critical chain is that it will enable you to finish your project sooner. And that’s why you would consider implementing Critical Chain while retaining your traditional approach. A word of caution though: Critical Chain implementation does involve a paradigm shift. To reap the full benefits of Critical Chain, your process will need to change. (see the pdf document by Realization that outlines how projects benefited using critical chain)
So with that in mind, the following outlines how to make the shift to critical chain organization wide. For the purposes of this post, I am assuming that the management is already sold on the concept of critical chain. If you are unsure of what critical chain can do for you, read how it can speed up project delivery. The second most important benefit for me was to predict project failure long before the project got off the rails. Fever charts that track buffer consumption to project duration is an excellent way to figure out when to act when estimates are way off or you are starting to fall behind. (continue reading…)
Flow in traditional project management process
Traditional project management works this way:
- Charter the project – include scope, ROM budget and ROM timelines
- Create a business requirements document. All requirements needs to be documented upfront and signed off by the customer. To me this is a contract that says what we will deliver.
- Architect then designs the solution. S/he provides technical specification to developers. Somewhere along the way, costs and schedule are written in stone. Another contract on price and timelines.
- Developers build it and pass it on to testing.
- Testers test to the requirements. By this time a significant amount of time has passed between documenting the requirements and testing
- QA releases to customer to testing
- Now begins a series of change requests (and in low trust environments finger pointing and assigning blame)
- Project is late
- This project now lands as a statistic in the Standish report as a project that was not delivered on time and budget
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. (continue reading…)


