![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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
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
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif){kind=small}
