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).

For the most part all of us have heard of these top five, in detail though how we address them is how we handle risk, and how we accept risk in regards to an IT project. The first one on the list, personnel shortfalls has been all over the news. We are constantly inundated with the concept that 150,000, 200,000, or more IT positions cannot be filled because there are not enough graduates, or not enough trained people to fill those positions. All the trade magazines and web sites have at least one article a month on this subject, and highlight the issues, as well as the complaints that there are not enough qualified candidates out there.

The answer to this is “no there are not enough qualified candidates, and that is a risk for any IT project including IT Security.” Qualifications though have to be defined against what the project entails. There may be many technically qualified candidates, but on the social side of the company, there are not enough. The other side holds true here as well, they may be socially experienced but not technically qualified enough for the position. The company and the candidate need to work out what are the Must Have, nice to have, and not really required skills, then both candidate and company have to be honest in their assessment of what the job requires. There is no use hiring a just out of college student with no hands on for a highly complex project, then getting angry at the hire because they don’t have the skills required to do the job. However, that is something that does happen with stunning regularity.

Companies, certification authorities, and Universities have both been trying to address the issue by providing incentives, cost reduction strategies like grants and scholarships. The real issue with formal education and certificates is that they work mostly on the theoretical level. Rarely out side of the technical schools are there any hands on experience if all they have is the degree or the certificate.

If the candidate has, actual experience in the technology that the project needs the choice of a good candidate becomes clearer. However, no one really addresses the issue of discriminating between warm body hiring and really finding the excellent outstanding candidates that company’s desire. The other problem is finding enough entry-level jobs outside of the military where people can be developed and trained according to company standards. All these then heterodyne into the “not enough skilled candidates for the job” or “personnel shortfalls” that are experienced by companies that have a high-risk high requirement product or project that needs to be completed.

The hard part for the security person who is shopping for a job is not only finding the place that works for them, but also working through the positions that are “Always Open” at a company. While a company may bemoan the idea that they cannot find the right people for the project, the “always open” never to be filled positions that litter academic, healthcare and technology company web sites is a disillusioning factor for the job seeker. The job may sound cool, but if there is no intention to hire those people who fill out the information for the job, and never are called, eventually give up in trying finding a job with that company.

If the company then develops or creates a legitimate job opening, no one will know, or the costs of finding someone get more expensive because a recruiter needs to find someone for them. While there may be legitimate open positions, and legitimate people to fill them, it has become a game of “whack a mole” to find a good job in the IT industry. Trying to then work through the hiring process, where days of round table interviews, questionnaires, profiles, and otherwise really puts the person seeking the job at risk.

The problem on the other side of the fence is that the company wants to make sure that they hire quality people that will work well in the corporate environment. To fix all this, the company needs to reduce the steps in the hiring process, have legitimate job openings, and still make sure they get quality candidates to fill the position. The job seeker needs to deflate the 8 in 10 resumes are inflated statistics, be honest, and understand that not all jobs are jobs the seeker is qualified for. Management will still whine that there are not enough people to fill positions, and job seekers will whine that no one is hiring. Nevertheless, ensuring that quality people are the ones that get through the gate to fill those thousands of open positions will work in the longer run.

The catch 22 situation that we have created in regards to hiring good quality people is systemic in the way that both jobs and seekers are created. Everyone wants the same thing, in that the company wants a person who is happy, dedicated, works hard, and does good things. While the job seeker is looking for a place, they will be happy, rewarded for being dedicated, wants to be rewarded for working hard, and has the ability to do good challenging things.

Resume inflation, and job description inflation (there is a classic one that was at Amazon in 2002 that has been discussed a lot in my circle. They wanted 10 years of Windows, Linux system administration, database administration, solid programming in C or C++, scripting, and security competencies as well as a high level degree, and all for 70K a year, the unrealistic expectations lead to many people abandoning wanting to work at Amazon for the time being). Both companies and candidates need to be more realistic, while 1 in 100 might have many exceptional well developed skills in place, most candidates are going to be normal humans that can do one thing really good, and many things ok.

Personnel short falls are going to happen; key people are going to leave. The project manger needs to sit down and work out contingency plans in case key people go, or key people cannot be hired in. There are options to this, outsource, hire a contractor or three, or otherwise bring the skills in house and reduce risk by pushing that risk onto someone else or some other company.

Not all companies are good at bringing a project home regardless of the issue, and that needs to be factored into the human equation as well. There are many ways to work through the process of personnel shortfalls. Project mangers, management and senior sponsoring management sometimes need to be creative in working out the solution that will best work for their company in addressing that requirement. As well, work out the solution for personnel shortfalls as the project matures or moves along in the development stages.

Comments

Tag:

Add to Del.icio.us | Digg | Reddit | Furl

Bookmark WebProNews:

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.

In the article Why It’s Time to Lose the Snide IT Attitude by Deborah Rothberg the premise of the idea is that the “classic” IT attitude, where “you are bothing me, why?” for all the trivial things that IT people do during the day has got to go. While Rothberg brings into the mix that people who have these kinds of attitudes will not get promoted. I will add that people with those kinds of attitudes also find themselves marginalized in the organization. Where the only option left to them to be effective in the organization is to scream, demand, and still not work with others. Winning the battle becomes more important than what the actual war is about. We have all met, seen and worked with people who always have to win. Eventually the do get left out of the bigger corporation, and might find themselves stuck in their position that will eventually mean their departure. In Rothberg’s article though this comment really stood out:

“Technology won’t survive with its thinly disguised contempt for users, aka customers. With enough complaints from customers, IT departments will either change or be outsourced.” (Deborah Rothberg)

This comment in context of the article makes one want to go and ask how many outsourcing decisions were made by business (because they are the ones that will make that decision) because they were unable to find any ground in which to communicate with the IT department or team that would normally work that that business line. The concept makes the idea that business just like any other customer will go elsewhere when service is not what they are getting, or the service is not what they need, or even worst, they think they will get no service or lousy service from the internal IT department. Every outsourced contract, every outsourcing decision made by the business units then becomes a failed project for the IT department. It is another lost opportunity to show business value, and an understanding of the business by the IT department. Over time, I agree with the idea that not only projects will be outsourced, but the entire department would be outsourced except for a few core individuals to provide continuity over time. Consultants by nature have to be more responsive to the customer, and they see the business as a customer and are willing to treat them as valued customers to keep what could be a lucrative contract.

In Rothberg’s other article, “Four Feckless, Counterproductive Business Approaches to IT” she states that these four things can impact the ability of the business line and IT to interact with each other.

Lacking a Long Term Plan – this is pretty classic Project Management, every major project and some minor ones that have a large impact should all have a long term plan on how they will not just be installed and used, but how they will be cared for and maintained over time. We all have been told in a rush to “just fix it”, and she quotes her source as saying:

“Fix this. It’s broken,” is one of the most commonly spoken interactions between business and IT units of an organization, and by many accounts, the first place communication breaks down. “One of the reasons there is distrust between the two groups is a result of tone. ‘Just fix it,’ people will say. The tone of it and the general imperative nature says ‘I don’t really care about this. I just want you to fix it.’ It implies a basic disrespect of the actual operation, to not care enough to understand why something is broken. There’s a difference in the curiosity and follow-through of business and IT guys,” said Bates.

Her second point on the process is “Rushing projects along, sometimes unnecessarily”. I have seen the impact of hard dates set in the project plan, that suddenly became soft dates, or the hard date didn’t really matter. This really impacts the department and ruins business IT trust because that IT department is going to turn and burn on the Hard PM date, and if they find that they didn’t have to go to all that work to meet an artifical date, they are going to be annoyed to say the least. She states though:

Right after ‘Fix this. It’s broken,’ the next most commonly heard by business to IT teams is ‘We need this ASAP.’ “The most obvious communication breakdown is instilling a sense of urgency where there may not be one. Everything is urgent, if we’re not completing it today, the world may blow up tomorrow. At the end of the day, we learn many of these things could have waited. It’s kind of like the blinders leading the blinders,” Brl said.

Her third one is pretty classic IT mythos, “Not knowing what they don’t know”. We all have known IT people that just would not stop thinking that they know everything about everything. We have also met Business people who are the same way. We might even find it amusing when both sides of the Know Everything fence are in the same room trying to work out a project. But she states:

“Nobody in IT expects business to know how to rewire a faulty router or upgrade a server system, IT managers expresses again and again, but they did expect them to know where their technology prowess dropped off. “Business guys tend to think of problems in terms of the technology that they’re familiar with, not understanding the magnitude of the IT process,” said Hewitt. A simple ‘do this’ can mean hours, weeks or even months of work on the IT side, where ASAP often only translates to how much business is willing to compromise to get a project moving on schedule.”

Then finally her fourth and final point is: “Blaming IT for project failures”. This is something that I have not only seen, but have been on the sharp pointy side of that blame as well. I know there are some projects that people have undertaken solo just to get the thing done because they can not or do not get the support they needed from anyone. Her point though on this one is the “point the finger game” that we have also all seen. The sad part is that the “Blame IT” part is so real, because of the “non-communicative” mythos that IT has.

“By most accounts, projects fail within organizations almost as often as they succeed. At the end of the day, someone has to take the blame for the failure, and all too often, this failure to deliver is dumped on IT. “It gets a bad rap. I think there’s a perception that IT is the cause of many failed projects, and they often get the blame,” said Bates. In psychology, there is an outcome called the “self-fulfilling prophecy,” which, in effect, states that in expecting something false to be true, these expectations are often met.”

Rolling these two articles together should be read by managers and by IT. While we can not help people who really do not want to be involved with other people, everything has changed since the early days. Now it is important to be communicative, social, and willing to work with people. That holds true if you are in IT or on the Business side of the house. Both articles can be found here and here.

Comments

Tag:

Add to Del.icio.us | Digg | Yahoo! My Web | Furl

Bookmark WebProNews:

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.

Sure it is important to follow industry project guidelines from the Project Management Institute and within the Project Management Professional (PMP) Certification, but I always keep these particular topics at the forefront of my mind ALL THE WAY through the project – from beginning to completion. Sometimes these factors can be overlooked or forgotten, or thought of as “not needed” in the rush to get a project underway. Stand Up and stop the madness, make sure you have a clear path before trying to get to your destination…. Or you will get lost along the way.

Key Measures:

1. Before even looking at business requirements or spending much time on a project, make sure you know:

a. Who the executive sponsor is and obtain the following information directly from that sponsor:

i. Project intentions and scope

ii. What the project is NOT or what is out of scope

iii. Who the “Customers” are for the project. (many times, customers are internal to the organization)

iv. If a Return on Investment document has been created and what is expected of a ROI document. What areas of the business are returns expected?

v. Project Budget and how expenditures are approved

vi. Expected Project Success Factors

vii. That they want this project moving forward at the present time, if not, when is it to start

viii. Timeline expected for project completion

ix. Agreement to put companies resources on the project to get it done

x. Required project status and reporting

xi. Agreement on a communication plan to sponsors, customers and other impacted parties

xii. Agreement as to the assigned project manager and support from the sponsor that if there are problems with the project that require the executive sponsors attention, that the sponsor will extend support for obtaining the resolution

b. Then put all of that information in writing, generally in some sort of project initiation document and then all project leaders, sponsors and customers and CIO SIGN the document. I cannot stress how important this part is. I cannot stress how many times we have come the end of a project and at least one of these parties (sponsors, customers or CIO) state they never agreed to some portion of the documented information in the project initiation document. This is especially important for System Implementation projects as a lot of time can pass between the time the project got underway and the time the final product is delivered.

2. Business Requirements

a. It is vitally important, before talking with any IT personnel (if the project involves internal IT – which, if it is system implementation, it most likely will) or product vendors, that you take the time needed to adequately document all business requirements from all customers. Documenting business requirements should, at a minimum, involve going through the following steps:

i. Identifying the subject matter experts and project representatives from each part of the business that serve as your customers for the end result of the project.

1. Identify the current problem or need

2. Document current processes

3. Discuss what is not working about the process

4. Review results they would like to see to support the business and analysis they need to perform to manage the business

ii. In business requirements documentation, DO NOT spend time discussing what systems or technology will allow them do. Discuss what is needed for the business. Do not let your customers try to define a process around systems or technology. Technology is there to support the business, not to dictate how a business should be run. Don’t worry, All the technical pieces will come together later.

iii. Document all the business requirements as discussed with all customer groups and subject matter experts. Be sure you specify the problems and needs, how it is hurting the business, what is needed, and how that will help the business. Be specific. This information will help you put together the ROI document to be sure the cost and expected benefits are in line with what the project sponsor(s) is expecting. Some project managers might disagree here and state that the ROI should be done before getting to the business requirements stage. However, I have always found new areas of investment (cost) and return on that investment present themselves when going through the business requirements discovery process.

iv. Always be sure to think about how a product will be used and how reporting will be required. This can really get you in the end if you don’t pay close attention up-front during the requirements phase.

v. You will then match the business requirements to the scope that you created in the project initiation document, or change the scope, which would require an amendment to the project initiation document requiring new signatures.

vi. Once the right set of requirements is documented and it lines up with project scope, then be sure to again have project sponsors, customers (remember, customers can be internal or external), and CIO acknowledging these are the business requirements, that the project is active and sponsored, and that they are in agreement with moving forward to the next project phases. This piece is especially important, as people tend to forget or say things like “I never said that” as you get further along in the project. You can always bring them back to the initial documentation and signatures. If you do not get signatures, you are a sitting duck.

3. Now it’s time to figure out how you are going to deliver on these business requirements.

This usually leads to a buy or build decision. That is, buy software from a vendor that specializes in the type of product needed, or build with internal IT personnel. The business requirements document is your basis for evaluating the buy or build decision. Do not stray; do not extend scope or budget, without going back through the sign-off process. If you are “buying” a product from a vendor, do the initial “paring down” process of determining top software products which match the business requirements.

4. Now that you have your top list of software contenders, have demonstrations performed by the vendors for your customer group(s).

They can help cast the vote for the selected product. It is critical to get buy-in from your customers every step of the way.

5. If possible, it is a good idea to perform a trial phase with 2 top vendors to see how the business requirements match up to the product.

6. After the trial phase, get back with your customers to demonstrate the products against the business requirements.

Then have your customers make their final selection. At that point, be sure a technical specifications document is written that matches up against the business requirements. The purpose of the technical specification document is to demonstrate within the product, how business requirements will be met, what business requirements cannot be met or can only be met partially, and the IT requirements for the product. Be sure that, before beginning a major development phase, that you have gone back to your sponsors, customers and CIO or other representative IT parties for agreement on the specifications and agreement for moving forward. This phase will also require an updated project schedule outlining the full development schedule, resource requirements, and commitment from involved parties.

7. Be sure to do a “pulse check” with your customers and sponsors at many points throughout the development cycle.

This will ensure your customers are not surprised by the end result or that you haven’t gone completely down a path that they did not want or that you developed something incorrectly. It is much better to catch these things while development is still going on – your time-line will probably be impacted much less this way AND the perception of project success by customers and sponsors will be much higher this way. Ultimately, it is best not to have any such “hang-ups” during the development process. But, it is probably not realistic to expect that you won’t have any. That’s the job of the project manager – to work through such issues and still complete the project on time.

8. When the development phase is complete, it is important that you have documented not only how to use the product, but how it impacts that business processes.

It will require discussion with customer group representatives about what the system will now do, and what the new process should look like. It is important to have this document and be in agreement with customer group representatives BEFORE any product rollout occurs. If you do this, you can expect a much smoother training and rollout phase of the product than if you just try to throw the product out there. If you do not have a carefully planned training and rollout phase, all your work will go down the drain, and the project will most likely not be perceived as a great success.

9. During the rollout and training phase, it is extremely important to communicate what the users need to do if they need help with the product.

What support for the product is available? A good project manager will already have this in place and be ready to put the support process into motion during the rollout and training phase. It is also important that you obtain agreement from the customer groups on the support process and that they think it will work for their group.

10. Lastly, be sure to follow-up with customer groups ensuring things are running smoothly and to see what problems or issues need to be corrected.

Keep doing so until your customers are happy with the product.

Remember, there are no levels of success. Either it was a great success, or it wasn’t.

Add to Del.icio.us | DiggThis | Yahoo! My Web | Furl

Hello, my name is Liz Davis and I have been working on System Implementation Projects for the last 13+ years in the high-tech and print industries. I am PMP certified and have worked for companies such as Informix Software, Synopsys, USA.NET and Cenveo.

The Virtual Project Office, LLC has been serving the CO community since 2006. Specializing in project management services for system implementation projects and Web Master design, Liz Davis offers 13+ years of Fast, Experienced and Professional Project Management services you can count on. Find out more about Liz at: http://www.thevirtualpo.com