airshipjones

The 80/20 Rule in IT Project Management

The 80/20 Rule states that in any project, 80 percent of the work will be done in 20 percent of the time but the other 20 percent of the work will require the other 80 percent of the time. That may sound counterintuitive, but from my experience, it is pretty close to true.

In any formalized IT project, most of the information for planning the project will be at hand and relatively easy to access. There are a plethora of tools for this, from spreadsheets to databases, to COTS reporting apps for monitoring and tracking. Gathering the info we need to get started is easy. That is what computers do best. The tail end of the project is where thing get tough because that is where the outliers and unexpected issues are, or should be.

When implementing an IT project, I always try to identify the easy wins and the high profile targets and make sure they are addressed in the project plan first. Easy wins help build momentum and build confidence, both for the team, and with the rest of the company. High profile objectives help to make sure the project is meeting its objectives and staying on track to complete its deadlines. But what about the project objectives which are not easy wins or critical to the timeline of the project?

I also try to identify project outliers as a part of the planning phase and make sure that they will be handled last and that appropriate time and resources will be allocated for those outliers. There will always be unexpected issues that will crop up and add complexity, and these require additional time and resources. There should be allowances made in the planning phase for the inevitable but unknowable issues that will arise. Planning for the outliers at the end allows critical work to be completed first. Key milestones should be implemented as a higher priority to maintain project deadlines without impacting goals upfront. Delays on the front-end can have far more serious impact than delays at the end of a project. Outliers, particularly if they involve technical difficulties, can impede the momentum of the project. These outliers may cause mixed priorities if allowed to overwhelm planning and objective management, but it is important to remember that they only affect a small portion of the project. A great example of all this is the project I managed while working for IBM. I was in charge of a project to integrate several different flavors of Linux and UNIX into an Active Directory environment. Most of this would be fairly easy to integrate, except that we also had to contend with AIX (it was IBM after all). The older versions of AIX didn’t have a PAM module. There was a custom LAM module with a LAM to PAM converter, but the configuration was finicky and had to be set specific for each machine. Those AIX systems were the outliers, and we planned to implement them last.

As a part of the process, we designed the AD environment, configured and tested it. We rolled out the integration scheme for a test batch of the Windows systems, which was successful, then rolled it out to the rest of the Windows servers. An easy win. We then implemented the OpenLDAP servers which would pass through the calls from the rest of the Linux and UNIX servers to Active Directory. This was the high priority part of the project. We tested that implementation, and after a few minor adjustments, we started rolling it out to all the Linux, Solaris, and HP-UX systems. Once that was completed, we moved on to the final planned part of the implementation, the outliers, where we knew we would have issues. We scheduled maintenance windows for each AIX system, took backups, and made sure we had a fall back plan for each system, as we slowly implemented the integration tools for each. Because the AIX systems required more planning, more work, and had more issues, they took almost as long as the rest of the systems combined, even though the AIX servers were only small percent of the total number of servers. Then we ran into the unexpected.

We were told after we had all the systems integrated that we also had to integrate our user management into the IBM Blue Book directory service, so that any user account for our systems that was not active in the Blue Book would not be active in our directory services. We had to scramble to develop some custom code to compare user accounts each night and disable any in our system that were not active in the IBM Blue Book. Fortunately, that did not take too long, and we stayed on target to meet our deadlines. As a part of this project we created a LDAP Cookbook for the schema we had created, since we had modified the Active Directory and integrated it with Linux and UNIX via OpenLDAP. Because the cookbook had been a part of the start of the project design and planning, we did not have to go back and try to document everything at the end. We just had to verify the documentation was correct and understandable to everyone else. We already knew the information worked because we had being using it in the integration process for each server type as the procedure manual.

The 80/20 Rule is a useful guideline for project planning if nothing else as a sanity check. If I can get 80 percent of the work done up front and leave the outliers and other issues until last, the projects always progress much smoother.

The orginal article is on my site with my other writing at http://www.troymckee.com

This one is about social media. Check it out - http://www.troymckee.com/social-media

I have a new site for blogging about IT stuff at http://www.troymckee.com. Check it out. I will be putting up info about IT related events, technical docs I am working on or have done, and blogging about social issues with in IT that I think are worth talking about. Feel free to spread the word.

We have a chance to buy the house we live in, but we're scrambling to scrape up the money for the down payment. One of the ways we're doing this is by having a yard sale. If you want to help raise money for the Rabbits to buy the Warren, Donate things for us to sell, help volunteer to do the sale, and/or come buy stuff!

Contact dany@therabbitwarren.org for more information.

What are you listening to these days?

I want to get input from my friends on a kinda weird question to help me calibrate my understanding of how people view walking distances.

So, here is the thinking in my head.

If I walk around the block, I think of it as having walked one block. But if I am describing walking directions, and I tell someone to walk four blocks, turn right and walk another 3 blocks, I think of that as seven block. But walking around a block is pretty much like walking the length of four blocks.

So how do you all describe walking distances?

Saw this retweeted, and thought it was worth posting up here. The gist is that people who multitask "have trouble ignoring irrelevant information", and can't "organize things in their working memory" and slows "how fast and readily people switch from doing one thing to another."



I think I need a new job.....

An Article on Wired.com. Read it now. Read it here.

Go. You will either be amused or thoughtful. And you will look at the people around you a bit differently, at least for the rest of the day.

This is reposted from Dawn's LJ. We are looking for a Web Dev for a project we are working on. Details are here:

http://purplerabbit.livejournal.com/#entry_226100