How long did it take to build ….?

I had a wonderful opportunity to listen to and Interact with Hubert Smits couple of weeks back. One of the questions he asked during the interaction is “how long do you think it took to build empire state building (the tallest one when it was built in 1930s)”? There were answers like 10 years, 7 years, 20 years etc.

Empire State
He replied saying 400 odd days with 3400 workers… Immediately the follow up question was to complete the architecture and design? He said “No…” to complete the entire building.

I couldnt believe it immediately. Went and searched in Google and found links confirming the same.

Some of the things which i could take as a lesson from this
1. It requires meticulous planning. I am not talking about creating a plan here… Continuous Planning.

2. The architect had previous experience in building something of this sort. But again, every project is unique in nature.. The risk management capabilities of this construction was beyond what we can imagine(identify, monitor, mitigate and track).

3. The architects produced the initial design in 2 weeks, based on their previous experience. But, they would have refined it continuously as they built every floor.

4. Though the architects had previous experience, they would have ended up in new challenges every time. The design and development would have gone through iterations to address these challenges and not based on a big design upfront.

What this confirms is that even an industry which is considered to be the oldest, builds things iteratively and not based on one single plan. Hmm… now we are almost near end of 2013 and we work in a modern industry. But these practices are still @ a level where people only talk about it in most of the places.

Now… i will come back to my favorite place. May be after 50 years, someone might be writing about Belandur flyover. How long do you think it has taken to complete the incomplete Belandur flyover?

Happy Learning!!!

Image courtesy of

vitasamb2001 /


A Thing or Two about Risks

In the previous post, we saw the case for explicit risk management in agile projects.

Before we move forward with Identifying Risks, let us try to set the context and see what is a Risk.

Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective – PMI Definition
Risk is an uncertain event or set of circumstances that, should it occur, will have an effect on the achievement of the project’s objectives ~ APM.

What is the difference between risk and uncertainity?
I found a good example explaining the difference from this book Managing Risks in Organizations – A guide for Managers.

When making decisions under conditions of risk, you know the probability ofthe risk event you are examining. When making decisions under conditions of uncertainty, you do not.

For example, before leaving home, If you look out the window to check the weather and find that it appears as if it is going to rain, then you are making a decision under conditions of uncertainty and decide to bring an umbrella with you.
However,if you check the weather website and learn that the probability of rain is 80 percent and this leads to bring umbrella to work, you are engaging in decision making under conditions of risk.

How do you handle Risks?
Once you have the list of risks, you can choose to either mitigate it or Accept it and move on or Ignore it.

I understand the part of Mitigating a Risk. It makes sense to me. But if you see, we have not identified risks for a long time. How is this different from identifying a Risk and ignoring it or Accepting it as a risk and move on?

Well, it is all about informed decisions. When you identify something as a Risk and due to whatever reason, if you decide not to mitigate it, then all your stakeholders will know this upfront and when it actually happens, it will be considered as a collective decision. As a Project Manager you have reasons of why we have decided to not to handle it. You do not have to panic and there will be no blame game.

Why do you talk about blame game here?
Well, Project management is all about handling emotions well. When something doesnt go right and have a negative impact the emotions will be at peak and everyone is human (Not Buddha). This can lead to blame games and will definitely lead to a lose-lose situation.

Hence to Cover your A, Cover your team’s A, Cover your Key stakeholder’s A, i feel it is very important to make informed decisions and Explicit Risk Management will help you make informed decisions.

In the next post, let us take a look at the key aspect of risk management. Identifying Risks!!

Till then, Happy Learning!!!!

Managing Risk in Organizations: A Guide for Managers

The case for Explicit Risk Management in agile projects

Risk is a fuzzy term — it can mean different things to different people.

If you search for “Agile Risk Management” in Google, though you may get lot of links there are very few links which will be helpful for you. I am sure, if you take any of the agile projects that are being executed, you will not see anything related to risk management defined explicitly.

Why is that?
Agile was created keeping a single team in mind. Agile is focused on producing a working software every iteration by automating any repetitive tasks. This leads to frequent customer deliveries. Transparency and Visibility are the core values. Risk Management is implicit in agile teams and happens continuously (or should happen) within duration of the development. That’s why in most of the agile projects you do not get to see any form of explicit risk management.

Is this the case today? If you are from a Services company, i am sure its not the case. Even, if you are from a captive center, its not the case. We do (or say that), we practice agile in distributed environment, where multiple teams are involved. In some places there are even multiple companies involved. In a smaller environment, where there is only one team, Stakeholders are from single company and the project size is small its Okay not to have an explicit risk management. If you have a large team, a project running for more than 3 months, you will be in a much better place by doing explicit risk management.

Wait a second. Isn’t this what we did with traditional software development (waterfall). It was just a list and someone maintained it. I am a Project Manager/Development Manager who is extremely busy. What benefits will i get by doing this?

Well, in one way, its more or less the same thing. You need a list. But earlier, it was created/maintained/managed by the Project Manager. Activities happened mostly during the initial stages of the Project. It was never revisited.

In an agile environment, you revisit this, take necessary actions every iteration. This may improve your success rate.

Apart from that, today the Delivery teams might be from different companies. Though your product owner might be aware of the Risks, but your Product Owner is not the only stakeholder. As a Project Manager, its your responsibility to keep all the stakeholders up to date with the Risks, Owner of the Risk item, the plan to address, steps that been taken to address (Ignore, Accept or Mitigate). In case if your project doesn’t succeed, this may be another document which might help you CYA and CY Team’s A.

In an agile environment, Risk Management as a process – no one person owns the risk management. The whole team is responsible for risk management with a clear owner defined to address each risk item.

Okay, Sounds like a good story. If this is so important, why do we not see this happening?

Most of the Projects will have common risks. The challenge is to identify Risks which are project specific. If you know how to identify risks, i am sure we will find a way to mitigate them. Its a lot of effort and makes you thinking. Probably that’s on of the reason why you don’t see this happening.

I am planning to write couple of more posts in this. Will try to address the following as part of the next posts.

  • Risks Vs Uncertainty, Known Vs Unknown
  • Risk Management Process
  • How to Identify Risks?
  • Risk Response Planning, Tracking (Risk Burn down Chart, Risk Profile)

In the past, whenever i tried writing a series of posts, it never happened. Hope this time i will have some more energy to complete what i started in this post.

Happy Learning!!!!