All companies have a risk tolerance, some companies have a higher tolerance for risk than other companies do, many follow few lead.
Those risks that a company is willing to take, either bet the company, or smaller risks like bet the product help define the potential of a company in survival, either as leader, follower or failure.
There are five key risk areas in IT projects that were identified by Baccarini, Salm, and Love in 2004. These are personnel shortfalls, unreasonable project schedules, unrealistic expectations, incomplete requirements, and late delivery of software. How project mangers work within the confines of these five risk areas will help determine the success or failure of an information security project. This series of articles takes a look at all five risk areas, and proposes solutions to them.
Risk management in IT Security is an important part of the process of ensuring projects work and the result will be used. While this is just one school of thought in the entire systems delivery life cycle (SDLC), the understanding of risk, and the risk inheritance amongst various products used is really important in understanding how security technology will be used, can be used, or not used (leading to security failure).
Unreasonable project schedules are usually a combination of not fully understanding the requirements, pulling dates off the calendar to meet a time line that was agreed upon by management and the project manager without really taking a look at the skill and quality level of the people doing the work. While it is great to have a time line and an agreed upon date, risk management means that the project manager and coordinator needs to have a realistic expectation of the people that will be doing the work.
While a highly skilled and competent programmer might look at something, bang out 14 lines of code and call it good, an inexperienced programmer might take a couple of days to a week to solve the same problem. A skilled information security person is going to look at an attack and go “here is what is happening and here is what you need to do” while an inexperienced security person is going to Google their way to success. These differences in skill sets if not accommodated in the project schedule will disrupt if not derail the project causing the project to extend out past the artificial time line set by the Project Manager.
Any good project needs to take into assessment the skill level of the people that will be actually working on the project. It is always desirable to have the best or most skilled on every project, but there has to be room for those with less experience to have time on projects as well. If the project is a low risk and the time line can slide, introduce the less skilled people in the organization to project work using those projects. And have your more skilled people being advisors to the less skilled people. This addresses the risk, promotes growth and skill level of junior level employees. If the project is a high value, high visibility project, assign the more skilled person to the task, but have the less skilled employee job shadow and learn.
This of course assumes things that should never be assumed. One that the highly skilled person wants to train junior personnel, and has time to spend with them, and that the junior personnel is going to want to learn from the more highly skilled one. As projects increase and timelines in the schedule seem to collide, the ability for all people on the various projects is able to work well with each other. This mentor mentee training may be a luxury, nor does it include the various personalities that will need to be part of this kind of organizationally supported training and growth path. This solution will not work well in all cases.
The other realistic viewpoint is that the project manager needs to build in room to maneuver on the project plan. Overestimate the time required helps take into account what may be variances in time, materials, and labor availability. A project manager that does not consider these, as well as other projects that rely on the same personnel can seriously jeopardize a projects schedule. Efforts should be taken at the project manager team level to make sure those resources that are in contention for multiple projects realistically take in human factors, such as other projects, holiday, vacation, and getting ill. As all these things will happen on a project regardless of what the project manager has put on their schedule.
The other thing that the project manager should consider is delivery of materials required for the project. The time lag inbuilt into the organization to order supplies, materials, computers, and other project contingencies that are inside the organization. Finally, though, the project manager should have a back up plan in case of the loss of the key employee (sickness, death, move on to another job, promotion) in the project plan. The loss of a key person can derail a project for months while a replacement is sought for.
Defining a viable project schedule against all these kinds of variables will help make the project plan more realistic, and while not eliminate risk, will reduce risk to the project. An unreasonable schedule does nothing more than tick off the folks who are working against that schedule. Having a more realistic viewpoint of the strengths, limitations, and weaknesses of the people on the project, the organization, and organizational sponsorship will help the project manger deliver a more reasonable project schedule. This will in turn help the project be more successful.
Tag:
Add to 
Bookmark Murdok:
Dan Morrill has been in the information security field for 18 years, both
civilian and military, and is currently working on his Doctor of Management.
Dan shares his insights on the important security issues of today through
his blog, Managing
Intellectual Property & IT Security, and is an active participant in the
ITtoolbox blogging community.
