Project management in the security space - trials and travails

Today's information security project manager faces the same dilemma that many engineers have learned to deal with over the decades - how to deal with incomplete information. Rigid time-lines do not allow for much flexibility when the information sought to complete designs or implement solutions is not available. Given the management concerns and compliance reluctance on release of ANY information even barely classifiable as sensitive, this happens more often than one is wont to believe. So how do project managers deal with this?

Some project managers I have worked with in the past have used the universal favorite - the segments of the project that could be held up by the delayed information are somehow contrived to be 'out-of-scope' - and the rest of the project is repainted as the complete project, and delivered 'on-time' and as an added bonus, 'under-budget' since the removal of the difficult items did not extend to corresponding budget corrections :)

Other project managers have made a fine art of this principle, using it fairly indiscriminately to always deliver projects on time and under budget or on budget. But this still leaves the base question unanswered - how do we deal handle getting the information in time? What are the project manager's responsibilities and practical options for dealing with the solution?

Here are some tools that I have found useful.

1. Education - Project managers need to comprehensively understand information security and information assurance, at least to the extent we understand the fields today, before they are asked to manage IA and IS projects. These projects have the capability to negatively affect both public image and the bottom line if not carefully herded through to completion with due diligence. While the project management skills requirements remain the same, these project managers additionally need to understand not just the politics in an organization but also the information security and assurance drivers within the organization, and their interaction with all connected external clients and partners, and the way the client and partner relations drive the information security and assurance processes.
2. Due diligence - This is true for any project - do all necessary AND apparently unnecessary investigation and research up front to avoid unpleasant surprises later. Investigate the relevance of all required data, and clear the same with legal, compliance and risk teams well in advance. If new data paths are being created or old ones removed, do the same check with the above teams - and repeat in case the one member not present in the original meetings has a difference of opinion. If anyone complains about redundant questions or questioning, repeat the question again - and then again, for good measure. One person's displeasure is fair play versus possible senior management unhappiness due to project delays and expanding budgets.
   
3. Measure risk - and report as widely as possible. Redo risk measures for all relevant systems, and all ancillary systems that could get touched. Develop a process to automatically (hopefully !) update risk measures of individual components as other components get added or deleted, or the metrics for a specific component change.
   
4. Work closely with risk management, help desk and computer security incident response teams - involve them from the get go to ensure that any incidents as the project progresses keep the project team in the information loop for necessary course corrections - instead of the 'end-of-project-review' when the security teams reject the entire suggestion!
5. Inform the architecture team (create one if the organization does not already have one) and ensure that there is a two-way flow of information regarding changes in the infrastructure and architecture landscape progresses: think of the number of projects that lost steam when someone realized that their work was no longer needed due to other design or business need changes.
6. Ensure business representation and participation - the project exists because the business felt the need for it, after all. No IT work exists in a vacuum - it is driven by business need and not vice versa.
   
7. The Information Security project manager needs SPECIAL people management skills. If you thought that IT professionals were a weird bunch, wait till you meet your first IT security tech. Then multiply that by 7 (the average team size ?!) and consider the fact that you will be closeted with them in conference rooms feeding them brain food (pizza and coke) for extended periods of time, at the same time having lost all contact with the real world. Think of spending sixteen hours at a stretch between fun terms like 10Base-T, Fuzzy logic randomizer, BMUS, CIA Triad , AES/DES/3DES, and YMMV interspersed by an extremely animated discussion (politic name for heated argument) on the relative merits of a layer two firewall versus a layer three firewall, or a unified threat management appliance versus discrete specialized components for each desired function, and their combined throughput merits.
8. Recognize excuses - and deal with them appropriately. Information security personnel are no different from the rest of the world - they succumb to pressure. Recognize the symptoms, and deal with it. However, realize that this crew is not really easily replaceable, and their inherent institutional knowledge is definitely not only replaceable, but takes a long time to reacquire for a replacement.
9. Pay attention to the undertone murmurings. In this environment, they could indicate potential show-stoppers, and make or break the project. Typically, most project failures can be blamed on poor management rather than technical ineptitude, but information security projects can fail for a new reason - changes in the information security landscape. Keep an ear to the ground, and follow the regulatory world with extra attention.
10. Love the job - Very important. If you do not enjoy this work, stay away - it can make a lot of people sleep a lot easier, including yourself! These projects can add feathers, but can also bring on the tar!

I would love to hear other's project management tales and experiences. So please share if you can!