I want to believe that a reader of this post needs no convincing that project management has already proven its effectiveness in every industry. Even in the age of Agile, traditional waterfall project management is still a worthy endeavor as Agile doesn’t address management of a project across disciplines or large projects. I don’t want to turn this post into a “Bashing Agile” post. Agile works great for tasks that all start and end inside of a single discipline or profession; it works great for small teams such as those in many software development projects. After all Kent Beck’s focus was improving software when he envisioned the predecessor to Agile, Extreme Programming.

The next logical question, how do we apply it? Well, if you are involved with capital equipment purchasing, it’s likely that project management is in use. Even in the IT security realm, project management has a place. If you aren’t part of the team or this is all new to your organization, I encourage you to dig into project management and find out what it is all about and how to apply it to the projects that you will work on in the future.

A few words of advice. When starting, don’t worry about searching and finding a project management software first. Develop a methodic system first, then look for a software solution. Don’t bother trying to find software for a solution to a problem that you don’t have yet. Yes, the software is great; yes, no matter the one you choose it will make the project seem more organized, but this category of software is not simple to use, even if it looks simple on the surface. Many people start with a grand plan then get trapped in thinking that they must list every possible task with minute detail in how long it will take to complete. All that seems great, but the novice user will quickly become discouraged with the seemingly irrational way the software behaves once adding predecessors is complete, and the tasks are all knotted up with each other. This behavior will make you feel that you are spending more time planning and no time doing. It’s best to start simple. Use a spreadsheet and list all the tasks that take longer than a day to complete. If there are many short tasks, group them logically together and treat them as a single task or better don’t list them at all and extend the time of the longer tasks that are related to include them.

Go ahead and add start and completion dates to the tasks, list the resource that will work on the task but don’t list the person by name, list by job function. Phil Carleen might be the programmer on the project but list his work as a programmer. This way, when he goes on vacation or changes jobs, the plan can continue with a new programmer without changing the paperwork. When estimating the time to get a task done; a good rule of thumb when starting is to double the estimate and maybe triple it. If you think the time for a bit of programming to make a pick and place move will take two days, put four on the spreadsheet. Seems crazy I know, but you aren’t listing the effort to program on the spreadsheet–not yet, rather you are listing calendar time, and they two easily get entwined. Estimating the effort a task will take as two days might very well take two days and maybe less, but what happens when a production machine goes down, and you have to spend three days working on that? Your schedule just slipped! Sure, you might hear people complain that it takes too long and when all the tasks are added up it might seem incredibly long. As you and your team gain experience and get better at estimates, the durations will change, and things will go faster. Trust me on this and trust that I predict you will be overly optimistic about how long it will take to complete those tasks.

Good luck

Jeff

References

Beck, K. (2000). Extreme Programming Explained. Reading: Addison-Wesley.

Brewer, J. L., & Dittman, K. C. (2013). Methods of IT Project Management. West Lafayette: Perdue University Press.

Whitman, M. E., & Mattord, H. J. (2018). Principles of Information Security. Boston: Cengage Learning.