Tuesday, May 31, 2011

Checklist manifesto

Management books are often boring and mostly not really applicable on your situation so they rarely makes good material for a blog post. A while ago my wife was told to read "The checklist manifesto" by her boss and once she was done with it I took a look and actually really liked it.

The core concept in the checklist manifesto is that there are certain series of rather simple steps that needs to happen in order to perform a complex process. The core example is the surgery checklist but Atul Gawande (the author) also uses examples from other fields such as aviation.

Can this principle be used in identity and access management projects? I would say definitely yes.

Good examples why checklists are useful are my two first IAM projects. In the first "first project" I basically had no clue on what I was doing neither on the process side nor on the technical side. Luckily I was in a very junior position so my lack of knowledge didn't doom the project. Interestingly many of the senior resources also didn't have any knowledge of the product but luckily the client realized this and hired a very seasoned person straight from the product manufacturer who managed to get the project back on track and utilized the quite impressive domain knowledge of the senior resources to create a very good solution. The project also managed to pick up some very talented technical resources along the way which helped quite a lot.

In my second project I had a very senior role. In fact I really wasn't ready to take on the role and the project suffered from my lack of experience. We as an organization also had some other issues that we had to work out and in the end I as well as the organization ended up being much stronger but it took a lot of hard work.

In both projects checklists we ended up creating checklists. In the first the main contractor already had a semi formal checklist for how to run IAM projects. They didn't know how to run an OIM project but they applied their general IAM checklist to the project and where decently successful. The initial design that they created was totally unimplementable in OIM but at least they had a design that after a few months of tweaks and changes ended up being implementable.

In the second project we didn't really have any checklists or any form of process until we got some help from one of the senior PMs. He had a general checklist for how to do IAM engagement and we also developed a form of general checklist for how to do offshore development engagements in IAM projects.

Once we had our checklists in place for how to develop, test and migrate the code we could start delivering code that did what the design said it would do. Now the problem morphed to gather the correct requirements so that you can create a design that solves the actual business problem. The requirements and design gathering process is much harder to codify so that was much more of a challenge and it took me a few more years to get to a point where I think I am getting a good handle on that challenge.

No comments:

Post a Comment