I like to share great articles I find – since we can all learn from each other. This one from ProjectTimes.com talks about a great book by Linda Henman on ‘Landing in the Executive Chair’ where she talks about what a leader should learn in order to prepare for a crisis and what a leader should do during a crisis. If you haven’t read the book – get it – but this article will give you the highlights and lessons that you can put into practice right away.
It doesn’t matter if you are using Agile – Lean – Waterfall – or some other practices…Crisis rears it’s ugly head in many projects – and when you least expect it. Project Managers will find these ten lessons of great value in preparation to minimize the impact to their projects and their organizations.
Lesson 1: Heed the Early Warning Signs
There are often early warning signs that a storm is brewing. Sailors have a saying, ‘Red sails in morning, sailor take warning, Red sails at night, sailors delight.’ Take notice of early warning signs in your project. Be aware of persistent customer, stakeholder or project member complaints, rumors, turnover in the project, and resistance to change due to innovation or technology. These always seem to start off small and begin to swell. Don’t ignore them and find out exactly if there is the potential of a problem brewing over the horizon.
If you want to scale Agile to the enterprise, then lets take a look at a few great points that Forrester presented from their Q2-2010 survey results this week that verified the need to scale Agile beyond a single team.
You’ve heard in many of my webinars that adoption of agile methods is not always smooth and many organizations are experiencing obstacles to their acceptance.
There is great news to share.
Agile is going Mainstream
It was interesting to see Forrester acknowledge that Agile is going mainstream and most certainly crossing the proverbial business chasm that Geoffrey Moore talks about in his book “Crossing the Chasm“. Moore divides organizations into 5 groups as shown in Figure below.
Summary: Requirement risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. agile practice can go a long way in mitigating those risks.
** A great article on Stickyminds, written by Ellen Gottesdiener that will show you how Agile practices can go a long way in mitigating the 6 most common requirement risks we see in all software projects.
Every software project carries some risk, but many of these risks can be mitigated. That’s true of problems related to product requirements—problems that are often cited as one of highest risks for any type of software project. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry.
What a delicate subject to broach. I will be an objective observer and not assign any blame on the gulf spill until the details are available, but I would like to use this tragedy to discuss how it relates to project risk planning. I am guessing that something was overlooked during the formal risk planning process related to the Deepwater Horizon oil rig drilling into the Gulf of Mexico.
I have been using agile project management methods for 10 years and have attended numerous agile training courses and conferences. In all of my training and experiences I have never heard anyone discuss formal risk planning as it relates to an agile process.
If you take agile training you will hear folks like me say “agile is continuous risk management”. This is a true statement. We take risk out of the requirements by working face to face with the customer. We take risk out of the build by continuously integrating the code. We take out the risk of delivering buggy code, or code that goes beyond the need, by using Test Driven Development. So if we are performing all of these practices do we really need to do any upfront work related to formal risk analysis and planning? The answer is yes, sometimes it still makes a lot of sense to do formal risk planning.
If you are not familiar with formal risk planning, let me provide a high level synopsis.
First we sit down as a team – executives, managers, business folks, and technology folks. We discuss everything that could go wrong with the project and create a list of potential risks. Once the list is complete we talk about the impact if the risk materializes. In figure 1 you can see an example of a risk assessment. In this example we note that Risk ID # B1, “incomplete migration”, only scores a 1 on the impact scale, meaning if the risk materializes the impact will be minimal.
Continuing with our example, Risk ID # B5, “Insufficient resources”, is scored as a 5 on the impact scale, meaning if it happens we are in big trouble. We probably will not be able to deliver any project value if this risk materializes.
Once the team identifies the impact of a risk, they move to the probability of the risk occurring. If we stick with our previous two examples, Risk ID # B1 has a .25 (25%) chance of occurring. Risk ID # B5 has a .75 (75%) chance of occurring. Since B1 is low risk and low impact, we are going to accept it and not do any contingency planning.
Since B5 is high impact and high probability, we need to lay out our plan for managing this risk throughout the project.
As I mentioned at the start, this exercise makes sense on some agile projects. I cannot provide specific criteria for you to use, but I can tell you what encourages me to do this exercise at the start of a project:
1) When I am working on a project with high dependency on groups outside of the project team.
2) When a sponsor or business owner has a history of delaying or cancelling projects due to disregard of project risks.
3) When the technical team sees numerous business risks that the business customer cannot see or envision.
4) When I am working on a CYA project. Agile is all about collaboration and shared ownership, but on occasion you may find yourself managing a project where you need to CYA due to the political environment.
5) Projects with a long period of time for iteration zero work (iteration zero is work needed to establish a foundation before coding begins, such as ordering and installing servers, working through contracts with vendors, and obtaining help from teams outside of your control). In my experience this would be a project with an iteration zero longer than 3 weeks.
6) When the customer wants to. If your customer enjoys this exercise and it makes them more comfortable on understanding the project risks, do it.
7) When an internal project management governance group requires this process.
8) Whenever you are using technology that has never been used by the team before.
Use your knowledge and experience as a project manager to help the team determine when this exercise provides value.
Lastly, when you do use formal risk planning do not consider it a one-time event. Find a regular day and time to update the risks and manage them throughout the project.
* * * * * * * * * * * *
Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Agile-Lean as possible….delivered right to your inbox weekly. No spam or junk mail. You can unsubscribe at any time.