I have been reading (in some cases skimming) the selections for Unit 12 on project management. One that I found especially interesting was the USDA’s Project Management Handbook. I was taken by how structured and formalized it was. It seemed that quite a bit of the handbook was spent in lisitng all the other government mandates that define how projects should be handled. That is the supposed curse in working for the government—one can feel like their hands are tied in having to comply with all the many rules and regs. I also found it interesting that it went into more detail then other readings on the importance and place of security in the IT environment, and different stages of the project. I think the document did a good job at differentiating between program and project manager, and spelling out the responsibilities of each, along with roles and responsibilities of the project team and client.

I contrast this with the article I read for the dropbox assignment: Reich, Sauer, and Wee’s Innovative Practices for IT Projects. As the title indicates, it has suggestions for novel ways to deal with issues that arise during a project’s planning and implementation. One message from the article is that it is alright not to follow rules if they would lead to a failed project, and even to encourage dissent if something is in the works, but doesn’t make sense. Somehow I see the authors of the Project Management Handbook dying of apoplexy if they were asked to take that article seriously.

Of course there is necessity for both works. The Project Management Handbook is useful for providing a solid government reference, and many people are most comfortable with having detailed, structured assignments and boundaries. But unexpected variables happen, and flexibility to respond in more a unorthodox manner, if it leads to success, is what Innovative Practices for IT Projects affirms.