Project Management uses IT and Business Relationships to Shape Successful Projects

The Trust Factor

Good relationships between IT and business partners, project managers and IT staff, and project managers and stakeholders keep IT projects on track, say IT leaders and project management experts. Bad relationships, however, are a leading cause of project failure. We've all seen projects that should have been successful fail purely because of relationship.

The impact good and bad relationships have on projects is clear: Negative relationships make people want to avoid each other or work against each other.

On the other hand, when mutual trust exists between IT project managers and stakeholders, IT project managers are more likely to discuss problems that could threaten the project as they arise. If bad blood exists between the two groups, project managers may not be inclined to point out those issues, or they may try to cover them up.

If you look at projects that fail, invariably someone on those projects knew things were going bad. If you don't have relationships and trust, those things don't surface and when you don't do something about problems in a timely manner, those problems invariably get bigger.

In many cases, minor problems become more serious because they're not addressed in a timely manner. A culture of openness is absolutely essential to good project performance. Ot should be part of your risk planning.

Furthermore, when something does go wrong with a project, business partners are less likely to place the blame solely on IT if they have some respect. In fact, they're more likely to give IT some leeway with the project schedule.

It doesn't matter what technology you're using, how talented your technology staff is, and how knowledgeable the business partners are on process and business improvement: Every system initiative will have issues.

If you don't have a relationship, you resort to pointing fingers as opposed to being transparent and admitting 'we messed up' or 'we didn't test that as well'. If you have a good relationship, you'll sit down and find a way to make it work.

Decisions affecting the project also get made more promptly when everyone involved gets along. Fast and good decisions are crucial to keeping projects on track. The failure of senior people to make decisions means decisions are made at lower levels of the organisation.

If you have a software developer who's waiting for input on a business requirement, there's three things that can happen: He can guess what to do and guess right. He can wait for a decision and while he's waiting he's not as productive. Third, he can guess and guess wrong. If those are equal possibilities, two-thirds of the time it will be detrimental to the project. And if you stack enough of those decisions on top of each other, it will negatively impact the project.

Relationships are easily Overlooked
Despite the positive impact good relationships have on project management, IT project managers rely more heavily on software and methodologies than on building relations when they need to improve their delivery.

It's no wonder: Compared to the time it takes to build relationships, software seems like a quick fix. IT project managers are also most comfortable with tools.

As IT professionals, we're raised on technology. Almost all the training we get throughout the years is about tools and processes.

Consequently, IT professionals think process and technology is the answer to everything, including effective project management. While project management frameworks and tools certainly help, projects are fundamentally people-driven.

When things go wrong with a project, it's people who have done something that didn't work. Problems start and end with people.

Yet project management training and certification programs are only just beginning to address the people-side of projects and the importance of relationship management. Most still emphasise task management.

Thus, project management training and certification programs reinforce the idea that project management is glorified task management. That's a big mistake.

A typical project manager follows the 80/20 rule: spending 80 percent of his time on task management and 20 percent of his time on relationship management, but he should be devoting more of his time to relationships.

I would suggest that the more visible, big-budget the project, the greater the percentage of the project manager's time should be spent on relationship management.

Agile Development and Relationships Using Scrum, an agile software development practice, to improve relationships between IT and business partners and ensure project success is one good approach.

With Scrum, business partners meet with IT during a four- to eight-hour planning meeting to look at all the projects in the backlog and to jointly determine which one will bring the greatest value to the company.

IT then divides the project into sprint's 30-day increments of work. When IT completes a sprint, business partners assess IT's progress and suggest any necessary changes.

The agile development methodology, just by design, promotes better relationships. Scrum and Agile force interaction between IT and business partners on a more frequent basis. By doing so, IT delivers solutions on an incremental basis to the business, as opposed to the waterfall or cascade method, where it's a year and a half before the business sees the fruits of an initiative.

It's not necessary for IT and other business functions to get along swimmingly for Agile to work effectively. Agile can work even if there's some initial tension between the groups.

We've all had groups with troubled relationships, and certainly most initial meetings are not always effective out of the gate. But at least we all can agree that we're going to focus on 15 key items in the next 30 days, and at the end of the 30 days, we'll get back to you.

The process forces IT and business partners to prioritize projects together and agree on the 15 items IT will complete in 30 days. Scrum also then drives IT's behaviour. At the end of that 30 days, IT has to show something for its work. Scrum makes IT accountable to the business.

When business partners see IT making tangible progress every thirty days, their confidence in IT grows. If the business partner sees results more frequently than they used to, relationships can get better. Agile promotes better relationships just by forcing a process, forcing interaction.

Between the structure that Scrum imposes and the relationships that grow out of it, project delivery improves. Better collaboration results in better value for the business.

The Sacred Cows of Roles, Process and Metrics

A View on Sacred Cows

There has long been some academic argument, theoretical disconnect and the occasional raised tension between the dedicated followers of business intelligence /performance management (BI) and those that stand behind business process management (BPM).

KPI and data evangelists sometimes view process advocates as bureaucrats no longer tuned to the dynamics of changing businesses, and are now more interested in outcomes than processes.

Meanwhile, the process faithful have worked incrementally and under a long-held premise that 'where business/technology initiatives fail, there’s normally a clumsy process to blame'.

Inside Process Initiatives
By their very nature, inside process initiatives draw little attention, being as they are usually secretive. The greater effect of business process outsourcing (BPO) has already shifted workforces for scale.

What started with call centre outsourcing, sooner or later touched internal departments for travel, payroll, time and expense, software development/maintenance and even CRM or other customer-facing applications.

Process and Data Converge

In the last few years we’ve seen the process and data worlds merge to the point where process conference speakers actually discuss business intelligence and vice versa. It’s that tentative connection of processes and KPIs (or service levels for BPO providers) that has led to some recent rationalising thoughts on soft skills and the beginning of what might someday become a wider and mor comprehensive use of on-demand employment.

Executive Ambitions and Goals

We have been learning about executive ambitions and goals inside global corporations. These normally culminate in the establishment of internal priorities for employees and the outsourcing of everything else. We have to be more thoughtful now and need to consider that data centre managed service offerings are replacing not only IT infrastructure, but also their discrete IT functions.

Where is this leading?
Well, as service based infrastructure and process providers move deeper up and into the enterprise, old roles are slowly moving towards silo containment and tiers of competence. This leads more and more towards the virtual external providers whose value has becomes more nad more commoditised over time.

Driving or Steering SMEs
This use of comoditised outsourced suppliers is what is driving or steering small and mid-sized organisations and feed the continuous discussions to appraise and determine if even key undertakings like business intelligence are effectively outsourced to service providers.

Corporations' Citadel Approach

The larger corporations are not going to be outsourcing business intelligence or even key data functions anytime soon. Having said this, the previous years of rapid organic growth has created a jumble of capital assets, business architecture and roles in enterprises, which are becoming less controllable and therefore less defensible to maintain in-house.

Proven Competency
If you accept that BPO vendors have demonstrated and proven their competency, it may be more likely that core competencies will be begrudgingly and tentatively handed over to process owners inside the organisation, to manage internal and external resources.

Controlled Handover
This handover is already happening in a controlled way at companies like HP, Ford and Cisco. We already have people managing this transition, in the form of project and program managers, whose roles are enjoying elevated backing and status.

The Future

There is still some work to be done but there is good reason to believe that, improved operational metrics, performance management and business intelligence, will bring with it the mover and shakers of the process and on-demand movements. We just have to keep to the path, fight the fight and hold the faith.

Risk Management; A mind set

To those who have not yet discovered it, security and risk management is a mind-set. When you go into a shop or restaurant, you may automatically check out the security and note where the exits are. If so, you will also check as to how secure the financial transactions are. How does the waitress handle the credit cards? How far the credit card machine is to staff and other customers. You will have noted the location of the security cameras, the lack of a security station or the location and the number of bouncers.

As a security and risk specialist, you will always be thinking about and assessing the security scenarios but not to exploit or take advantage of it but to be aware. You cannot switch it off, its the way you are. It is the same for members of the emergency services, never really off duty.

Security Compliance

If you have to consider a risk management approach to security compliance, as part of your many regulatory obligations, the best way to approach compliance is through risk. It is ineffective to focus on the bare minimum, just ensuring you are simply compliant. Threats and vulnerabilities are forever mutating, growing and changing. The bare minimum is not enough. This is the first principle of IT security and of risk-based IT management.

When looking at new applications, components, systems or architectures, check out the risks to your business and the risk to your core information. Those are the important things to note. You are concerned if it meets a line item associated with HIPAA and SOX.

Pattern recognition

The 'always on' risk management mind-set is always looking for patterns, checking out ways of doing rather than items on a regulatory checklist. You will look closely for items that pose a threat to your core assets, those that you are responsible for and have dedicated your reputation to protecting.

When somebody comes to you with a potential security problem, even if you know nothing about the particular system or application, you can assess it by the application of the risk framework and therefore formulate a validate set of pertinent and probing questions.

Secure games

Most security and risk managers live and breathe in a security mind-set, whether they are hardcore techies or recruits from the business side. The methodology they follow day by day at work is the methodology they live by, outside of work. Even at conferences, when they unwind afterwards with a soft drink, they invariably play a Where’s Waldo? version of security gaffes, competing to see who can spot the most security lapses. It can appear very weird and a little black, if you are outside the circle.

Nailed by the business

The mind-set can have its limitations and can be self-perpetuating. There is an old adage that says 'If you are a hammer, the whole world looks like a nail.' Indeed, when taken by surprise, the average security and risk manager is typically out manouvered by something that happens on the business side.

Good grief! Have they learned nothing? You can’t believe that the business would make such a decision. Just because you have a structured, risk averse and secure mind-set, you forget that 'normal' people don’t always think that way.

Damage control

What happens next is up to you. If the security has been jeopordised or the risks are too high then it is your task to get it back into line and put the geni back in the bottle. The fact is clear, you are dealing with consequences. The business has taken a chosen path and you have to control the damage, mitigate against it or make it right. After all, isn't that your job as security and risk 'support' person? In reality, you are seen by the business (suits) as being in the same category as the IT help desk and that is all you are.

Although it is accepted that the security and risk manager serves and protects the
organisation and its profits, until it can be unequivacally determined how you can directly make money and grow the profits for the organisation, you will always be considered as merely a supporting act. So, let's make up and get on with it! The show must go on!

PM for Network Professional

Good Timing is the key to Good Project success!

Professionals know what they know and network professionals are typically well-versed in the technical aspects of networking: protocols, router and switch configuration, server deployment and management, and so on.

Conversely, we don't always know what we don't know and our colleagues, the network pros, are rarely trained on how to manage projects. Fortunately, most of the problems that networkers face in projects can be addressed and mitigated against using standard project management methodologies and techniques.

Consider the effect of some Probability and a little influence from Evolutionary learning can have on your projects. If you are not proficient in something but do it often and long enough and are determined enough, sooner or later you will start to have a greater degree of success or a lesser degree of failure. Design and install networks long enough, and you'll be sure to have some of those projects go awry due to predictable, 'unforeseen' 'surprises'. Two words that you do not want to use in your monthly Project Progress Report. Two words that clearly depict the reasons why you should be applying Project and Risk management methodologies.

....and then they put the phone lines in!

Sometimes the infrastructure you need, such as power in a communications room, is not ready when you need to install an Ethernet switch. Other times, your network equipment vendor may seem to be perpetually on "back order" with the one module you need. Or perhaps it's the all-too-familiar "scope creep" when users decide they need greater wireless coverage than they asked for at the beginning of the project, without increasing costs of course.

Managing network projects is not an exercise in fortune telling, far from it. When analysed the core components for network projects are just like any other project, IT or otherwise: There is an objective, a time line, a budget and expectations of those who will benefit from the network once it is completed.

Professional project managers command good salaries because they understand these processes. Executives know that certified project managers are less apt to have projects run away from them. Attaining project management certifications such as the Project Management Institute's Project Management Professional (PMP) could be just as valuable to you as a network professional as a Cisco Certified Internetwork Expert or a Microsoft Certified Systems Engineer but you don't have to earn the full PMP certification to reap some benefits.

Applying a few simple project management tips will quickly earn you a reputation for delivering network projects on time and within budget and this is the sort of reputation that opens doors.

Quick Fix is leading but .............!

Triple constraints; I once saw the following on the wall of a drive-in oil-change service: "You can have it done cheap, fast or right; pick two." This is true of all projects, and it illustrates the so-called "triple constraints" rule: projects are subject to cost, schedule and performance parameters. Changing one will affect at least one of the remaining two. e.g. when installing a network for a local bank branch office to allow for Internet access and e-mail. The project includes configuring a Microsoft Exchange server and installing a virtual private network firewall for security. You included labor in your project schedule and quote to ensure that the project is done in two months, as requested.

One week into the project, the bank announces acceleration in plans, the office network needs to be done in three weeks instead of two months.Your staff is already fully devoted to this and other projects. You can't cut out functionality because the office still requires all of the network connectivity and e-mail functionality. What can you do?

The only way to accommodate is to add more staff, either by paying overtime to your employees or subcontracting another IT firm. Either way, the cost will go up, yet the bank will likely baulk at the new cost. At that point, armed with the understanding of the "triple constraints" principle, you as a network pro knowledgeable in project management concepts can calmly explain why the request to change time will increase the overall network project cost.

......there be monsters here!

Project charter and scope; To reduce the likelihood of the network project growing uncontrollably, make sure that everyone understands the project deliverables, what the network will provide, how long it will take and at what cost. Your key constituencies here are the project sponsor and the network administrator.

By following project management methodologies, this can be accomplished by starting from the general (project charter) and migrating to specifics (project scope).

For network projects, the project charter could be simply "provide network connections for the new Shelbyville Bank and Trust building at 3 Main Street." Details including the number of connections, security protections needed and services desired are best left to the project scope. The scope simply supports the goals defined in the charter while providing more details; it is not a complete network engineering plan in itself.

You can create an initial cost estimate for the project from the scope. When the scope is broad or when there is only a charter, precise estimates are not possible.

A good option, is to take a network project of comparable scope that you worked on previously and use that as a basis for the estimate. It's also wise to not give a single figure estimate but rather a range, say maybe 50 percent on either side of the estimate derived from historical knowledge. As the scope is more clearly defined, refine the cost estimate by changing the midpoint as appropriate and reducing the range size.

Project schedule; Once scope is known, a project schedule should be determined. You'll already know the two most important project points: the beginning,following soon after the project scope is approved and the end, when the network is in place as requested by the sponsor. It's up to you to fill in the blanks.

Here's where a project management software package such as Microsoft Project really comes in handy. It can tie all aspects of the project together by providing a relatively easy way to create the plan for the network installation. Setting up the project plan can take some time at the beginning, but it will pay dividends many times over the course of the network project.

When planning network projects, break the project into the following six phases:

• Information gathering—scope, existing infrastructure
• Purchasing decisions—which switches, routers, firewalls, servers and so on are needed
• Ordering equipment
• Configuring and installing the servers and network equipment, and testing connectivity and functionality
• Customer acceptance
• Documentation
  

However, you decide to manage your network project, breaking it into smaller miniprojects makes the overall project more manageable. Suppose you know from experience that you generally receive network equipment from your supplier four weeks from order. Furthermore, you know that it typically takes two weeks to configure and burn in the equipment and another two weeks to install and test. So, start from the end of project date and count backward eight weeks; that then becomes your milestone date for ordering the equipment.

Scope creep. Performance constraints can also change, and in networking, they are usually on the side of more functionality, not less. Scope creep is a change in project requirements after the project has been planned and is under way.

A common example of scope creep that every network professional I know has experienced, is when the customer decides he needs more network capacity (number of jacks) than what you planned for at the beginning of the project. I like to inform customers upfront about the magic number: 24. Many vendor enterprise workgroup switches have a minimum of 24 Ethernet ports (some allow 48). Pass the magic number, or a multiple thereof, and expect the project's cost to increase (refer back to the "triple constraints" rule).

Of course, changing the number of connections does not just affect network electronics costs. Additional cable drops and possibly patch panels for terminations may be needed. An increase in electronics (switches or servers) may require heftier uninterruptible power supplies and may increase heat generation, forcing an upgrade of the HVAC design of the communications room or data center. It's clear to see that expanding the project requirements increases its cost, which is a problem when budgets are limited and fixed.

These problems exist because all involved with the project; the sponsor, network administrators and the other stakeholders (end users, equipment vendors, cabling contractors, customers), assumed that everyone was in agreement at the beginning of the project. But this was not the case. When all parties agree on and understand the scope at the beginning of the project, it is less likely that scope creep will occur.

Finally, should the scope still need to change, simply create a new cost estimate and timeline to accommodate the scope modification. Changes are not necessarily all bad, as long as all involved understand the effects that any changes may have.

Closing out a project. Once the network infrastructure is completed, there are still three major tasks to accomplish before the project can be closed. The first is rather obvious, ensuring the network functions as the customer intended. The customer should perform as many business-related tasks as possible to test the infrastructure and formally sign off accepting the project when complete. The latter will prevent end-of-project scope creep as well as provide a milestone for you to close the chapter on this project.

The second job, too often neglected, is to fully document the network. Remember, one of the goals when the project scope was created was to ensure the manageability and supportability of the network. Network drawings, router configurations, circuit numbers, server disk partition information, IP address assignment—anything and everything that was pertinent to the successful completion of this project should be documented and stored where it can be easily retrieved.

Finally, network projects rarely go exactly to plan, and sometimes surprises occur that could really not have been foretold. A postproject review, particularly of what went wrong, will help prevent the same mistakes from happening on a future project. I recall one network installation in which a concrete slab was poured before conduits were installed, necessitating cutting the slab to install the conduits. The lesson learned was to include regular on-site network infrastructure inspection dates as tasks in the network project plan.

For more information; You don't have to be a certified project management professional to take advantage of project management techniques to aid in your network projects - but it helps!

There are numerous Internet resources related to project management, including the following:
The Project Management Institute is the source of the Project Management Professional as well as other certifications. In addition, Prince2 is the preferred project management methodology and certifications in Europe, particularly in the U.K.

Stop your IT Projects getting canned

To weather the current economic maelstrom, enterprises are not only reducing head count but also are cutting back on ambitious or long-term projects in IT. Knowing how best to keep your IT project in the pipeline could mean taking a cue from those best versed in achieving project approval: Project and risk management business consultants.

Companies are cutting back significantly this year. They're under more than usual pressure to optimize every dollar, to either stop the bleeding or start the recovery. The key to retaining business is to build /re-enforce customer loyalty. This is demonstrating that continuing with your current initiatives should not only cut their costs but also help generate additional revenue.

What's true for consultants is equally true for IT managers looking to kick-start an internal project or to keep their project funding flowing. Those who are best at proving the value of their projects will win. And when it comes to uncertain times, keeping your project off the chopping block can end up saving your future and enhancing your career. There are many ways to do this and I would like to suggest a few.

Benjamin Disraeli
Benjamin Disraeli, is reputed to have said that there are three kinds of lies: lies, damn lies, and TCO/ROI calculations for IT projects.

Clearly, no professional right-minded company will pour money into IT without a strong business case. There has to be a payback and that final payback is that the business will get something beneficial in return. Before you can be a part of this, you will have to address the issue of choosing the right metrics and presenting them well.

Calculating the true return on investment goes beyond demonstrating cost reduction or bottom-line enhancement. Those days are gone. Today's executives are no longer likely to let simplistic metrics pull the wool over their eyes, after all, presenting statistics and compiling business cases is part of their job too. You have to provide something they can sell on to their people.

ROI dismissals
As we move deeper into belt-tightening, we are seeing more and more ROI calculations being dismissed. Most ROI calculations from vendors are flawed toward magical and large returns, and most calculations from users are too simplistic and unreliable. Bottom line: accountants don't believe them and cannot use them anymore.

Though numbers can't be rejected entirely, the kind of numbers you use should vary depending on the ultimate goals of the project. Despite being a great decision-making tool, ROI is often a misleading indicator for deciding whether a project should be pursued or not.

Case Studies Testimonials
Reliable case studies showing how other organisations implemented similar projects successfully and achieved positive results, may have more credibility with cynical management teams rather than simple ROI projections. All you have to do is find the appropriate cases.

Hard or Soft?
If the project aims to reduce head count, inventory, or transaction costs, so-called hard ROI numbers may be sufficient but for projects with less measurable aims, e.g. improving the business environment or coping with service provision changes in the competitive landscape, soft ROI, e.g. the increase in growth potential or business value as a result of improved relationships, comes into play.

Thus, positively demonstrating the beneficial value of your project can prove tricky, but if you focus on added and hidden value in these areas and make a strong case, you will significantly improve the likelihood that your IT project doesn't get canned.

Helicopter views
But don't focus too narrowly on your project's niche lest you lose sight of the big picture.
IT managers always need to step back and look at the impact their project could have on the entire organisation. You need to look at the cost of lost opportunities. What are we not going to be able to do, in terms of people, hardware, software, training and other monetary issues, all because we took on this project?

Will we be able to do more of what we do well or do what we do more effectively? Will this give the company, service or product a competitive edge in the marketplace? It can't just be a cool thing to do anymore.

Business needs direct IT
The true business need meets the true ROI. If the business has asked IT for a helping hand in a project, that should be enough. If you're doing an IT project that is either not driven by the business or does not have direct bottom-line financial impact to the company, you should not be doing the project in the first place. Would you have the business or IT shop do an ROI on something as basic as an e-mail server? No one would tell you that because there is no ROI, therefore we don't need it. The business need bypasses the requirement for IT to sell an ROI back to those who requested it in the first place.

Customer loyalty
Building and re-enforcing customer satisfaction and loyalty is paramount in troubled times. Despite the cost, executives will approve high risk investments because the cost of not doing the project in terms of dissatisfied and lost customers, can be far greater than the addition of new IT capabilities. Projects that reduce customer retention costs or increase the efficiency of marketing campaigns are more likely to get a green light.

Making it real
Even the most ruthless, cost-slashing IT project can die a swift death if it's pitched in language your accountant can't understand. Be aware that everybody talks and thinks about TCO and ROI just a little differently, depending on their view. It may help to manage the differences in understanding by the creation of a glossary or terms definition, distributed to the key executives.

Language
As the PM, you are the communicator and you need to have a sound understanding of whatever language your company works in. Do they use internal rate of return, payback period, time to value? Sometimes business leaders don't always sync up to the value language of the company. If capital is involved, you need to understand the process your finance department uses to approve the budget and get it into the language they speak.

Keeping it real
Business case assumptions must be thoughtful and clearly supported in terms an accountant will understand. Include metrics on power usage, maintenance contracts, and head-count savings. These often can't clearly be seen until the next fiscal year. Accountants crave short term gains and cost-control drivers that help manage long-term planning.

If you can show payback for an IT investment over 18 months or less, even better. Accountants love to recover the cost of expensive volatile technical assets before they're fully depreciated. They know the rapid rate of obsolescence in high tech toys, the lock-in tactics and the long licensing traps.

Don't stick your neck out
Embrace Optimism when you can. All projects rely on assumptions and the associated risks. The bigger the project, the bigger the risks. The key to getting your project approved is simply to do your homework. Study, analyse and assess the risks rather than assuming the best and being surprised by the worst.

Positive risk management
Planning for a positive outcome needs implementing better risk management, plus the provision of accurate financials, supported by proven program management methodologies and earned value. Also, you will gain more oversight and control with smaller and more frequent milestones.

It's better to be transparent and realistic about everything but base your budget contingencies on sound risk management analysis and assessment. You should never presume to receive 100 percent of a project's costs initially when you don't know 100 percent of the project requirements. Manage the risks and issues as you go and adjust your expenditure according to your project plan, risk management actions and develop a positive outlook in the team. Look for positive risks; opportunities and assess them as you would a negative risk, fully.

Building a project
PMs and IT managers will find it more palatable to take a staged or phased approach when pushing ambitious projects, one that relies on shorter, clearer milestones with conditional metrics tied to future funding. If you cannot get funding for the whole project because of skepticism of deliverability or payback, ask for phased funding. Each phase can have a checkpoint where progress is measured and funding for the next phase is approved or denied. If the business isn't happy with progress or results, there is much less risk.

Messy eaters
Try scaling back and down to move forward. Keeping your project off the pig swill scrap heap may mean settling for a digestible piece of the pie instead of the whole thing. That way you don't kill the chef and you can always go back for more later.

Even a broken clock is correct twice a day!

Dirty Laundry - leaking Security

Oh what a tangled web....
Your security providers cannot, and will not, tell you the whole truth about their security business because security is a state of mind. An illusion based on perception and relativity.

We accept the need for security service providers to specialise in the protection of our functioning environments and see their task as preventing or reducing unacceptable risk. You would be very naive to think they do this for altruistic reasons. The goal of the security market is to make money and they are doing very well, thank you.

As with all profit focused companies; 1) Security companies specialise in niche markets and have varying degrees of success in these markets 2) There are universal weaknesses in the structure that are not being addressed because;

• the technology or algorithms are not sophisticated enough, yet
  
• the market won't pay the price in restricted access, additional filters /controls that slow throughput and diminish transfer speeds
  
• they are chasing a shape-changing, highly motivated and relentless attacker, some of which are government sponsored
• Others
  

Here are some secrets of the security industry and practical ways to command honesty from your trusted security providers.

• Antivirus certification omissions - One of the biggest secrets in the industry is that, while antivirus tools detect replicating malicious code like worms, they do not identify malcode e.g. nonreplicating Trojans. Although Trojans have been around since the beginning of malicious code, there is no accountability in antivirus certification tests. Today Trojans and other forms on nonreplicating malcode constitute 80% or more of the threats businesses are likely to face. Antivirus accountability metrics are simply no longer reflective of the true state of threat.
• There is no perimeter - If you want to fight on the perimeter then you need to define where and what the perimeter is. Is the endpoint the perimeter i.e. is the user the perimeter? Is it not more likely that the business process is the perimeter, and the information itself forms part of the perimeter too. It is unlikely that you design your security controls with no base assumption on establishing a perimeter. The mistaken assumption we tend to make is that we have established controls at the perimeter and are therefore secure. Unfortunately for many types of threats, we could be very wrong.
• Risk management applies - Risk management threatens vendors. Risk management really helps an organization understand its business and its highest level of risk. However, your priorities don't always map to what the vendors are selling. Vendors focus on niche markets and individual issues so you will continue to buy their individual niche products. If you don't have a clear picture of your risk profile and priorities, vendors are obliged to set them for you. Trusted security partners will provide options for assessing your risk posture and help you develop plans to make the most security impact for the least cost and complexity. Security needs to conform to and support your business priorities. Too often, vendors want your business to conform to their product portfolio.
• Vulnerable People are more of a risk than weak software. - There are 3 areas to be considered where security is vulnerable; 1) software 2) weak configuration and 3) people. The lion's share of the security market is focused on the so-called software vulnerabilities but not so much on the other 2 areas. The people factor is the largest uncovered area of risk. This is malicious code that doesn't leverage a vulnerability but rather leverages the vulnerable person. e.g. downloading a dancing skeleton for 'a spooky good time' (this was a trick employed by Storm), social engineering, spear phishing, etc. While we still need to find software vulnerabilities and patch them, we must understand that an organization is only as strong as its weakest link (the user). And more attention needs to be paid in mitigating the other two ways beyond software.
• Can Compliance threaten security - Compliance in and of itself is a good thing but it does not equal security. At the very least it's a resource and budget conflict and it can split our focus. Compliance is there to raise and maintain the minimum standard of security, but in its weakest form, it only maintains the minimum requirements.
• What is easy to measure is not always the most valuable - If you have 15 software vulnerabilities last month and record that 12 of them have been patched, is this a true reflection of your effectiveness. It is much harder to measure how effective end user training was to make administrators immune to social engineering attacks. You need to be compliant, but don't allow your entire risk strategy to sit back and relax, based on it.
• Vendor blind spots allowed for Storm - Storm is being copied and improved. The Storm era of botnets is alive and well, nearly two years from when it first appeared. How is this possible? 1. Botnets thrive in the consumer world where there is little money for innovation. Storm and its controllers know and survive on this. They are making money out of everything from spam to pump-and-dump stock scams. 2. They seem to be able to eat antivirus techniques for breakfast. A lot of the techniques and innovations used by Storm are not new; they are just being leveraged artfully against the blind spots of antivirus certifications and antivirus vendors. 3. Malcode does not need vulnerabilities. Most of the Storm recruitment drives have leveraged social engineering and play off of a holiday or sporting event. Go team!
  
• Product v Process - Security protection has established itself as a huge professional business. "Technology without strategy is chaos". The security market is too focused on the latest red hot top box or super scorching technology. The shear volume of security products and the rate of change has super-saturated most organisations and exceeded their ability to keep up. Organizations realize only a fraction of the capabilities of their existing investments. Furthermore, the cost of the product is often a fraction of the cost of ownership. There was a time when you could "do it yourself." But the simple days of Virus meets Antivirus are long gone. Highly effective organisations are embracing professional and managed security services to extend and augment their in-house expertise. By focusing your in-house expertise on what you know best i.e. your business, the scale comes from teaming with third-party expertise. This will be increasingly necessary in these tough economic times.

The primary goals for executives is to squeeze cost, whilst maximising profit and reducing complexity. Today we are seeing a massive convergence in the security market. In a guard-dog eats guard-dog world there are soon only going to be a few big dogs left and a bunch of smaller mutts. Will the consolidation dogfight lead to better efficiency or will it lead to a vendor lock-in?

As company leaders and executives continue to squeeze and simplify, they will face many choices. Simply following the reduction of vendors by consolidation, may fail to meet their needs and balance their fragile cargo; cost, complexity and risk. Do vendors have a responsibility in this equation? Will they rise to the challenge? True risk management can show how and where you can adjust and prune appropriate solutions,

The key is using risk management methodology to drive responsible simplification of business processes and to take control of the future.

Why Projects are Failing

Warning!
Projects can go up as well as done, especially in the current economic storm.
Project management has been a big part of my business management career for the last 35 years. I attended my first course in project management in the early ‘70s. Since then I have accrued a large collection of practical theories that I would like to share, starting here with the bogey man of project management, Project Failure, how to avoid it.

GOAL!
Like all good team managers or players; Start by considering the goals!
Projects have 3 basic criteria by which they are measured. They are deemed to have failed if they do not meet the following simple success criteria:
• Deliver project within planned timelines – TIME
• Deliver project as per forecast budget – MONEY
• Delivering planned results – BUSINESS BENEFITS

Only around 30% of projects achieve all three facets of the Golden Triangle, especially the last one; Business Benefits, the project ROI, the business case justification, call it what you will.

Projects Delivered or abandoned?
Partly successful projects are deemed to be ‘delivered’, even if they fail on one or more of these criteria. According to Gartner this can account for 30% of projects. They also believe that 15% are wisely cancelled before the end, having failed outright to meet their original criteria. I can only surmise that this last group did not seek expert PM rescue advice to determine if they could pull it back from the brink or limit the damage. Instead, we will assume that these projects had a high certainty or potential for failure.

Thus, it raises the questions;

• Were they doomed from the start
• Did they lose direction or support on the way
• Were they really viable and therefore saveable
• Others. Discuss!
  

Very few projects that are struggling have the reporting visibility that allows executive management the knowledge and insight to determine their real status. There is a conspiracy of silence and misinformation that prevails, along with the belief that all is well, right up until they crash into the buffers. So, for the 15% of projects that fail, let us speculate that it should have been clear for some time that they were struggling and needed to be euthanised, if only we had known earlier. Discuss!

Mid Zone muddle
With around 30% of projects succeeding and 15% failing, we need to consider the 55% remaining projects in the mid zone, struggling for a foothold in the ‘shallows’ and ‘shifting sands’ between success and failure. Do these projects ‘partly succeed’ or ‘partly fail’? Are they caught up in some ‘timeless whirlpool’ that cycles them, infinitely? Clearly, not. They would run out of money, time or support for never to be achieved benefits. If we want to draw sensible conclusions from statistics, we need more accurate reporting methods, with more precise detail and granularity. Build in tighter controls. Build a better dashboard. Lead this ship of lost souls out of the doldrums.

Choose Success or Failure?
Moving on, let’s get back to the big fight; Success v Failure. The first question to be considered is; Should we be,

1. Considering the key factors leading to success or the risk of success or;
   
2. Examining the sources of and risk of failure?
   

They are linked, of course but one is intrinsically passive and reactive, whereas the other is more proactive. In Project Management and in business today, we need strong proactive project management resources that encourage, understand and support, the risk of success and can quickly recognise the need to mitigate away from failure.

In the latter stages of a project, this turnaround from imminent failure to possible success, can be achieved by bringing in an experienced rescue PM. They will quickly assess the damage, examine the mitigation potential and plot a course out of the swamp.

How? Simply through the disciplined use of proactive PM methodology and tools, plus the implementation and positive use of strong Risk management approaches. Oh Yes! and the benefit of decades of PM experience. Call me sooner than later.

Remember: Charismatic figureheads need to be ahead of the crowd! AND the crowd need to be behind them, all the way! (not as easy as it sounds)

Project failure starts at the begining

We are all familiar with countries, towns and destinations that are difficult to reach, either by road, rail or public transport and yet people exist there and thrive. It is not in another dimension or another planet, where predictable 'difficulties' are numerous e.g. expensive ad hoc rocket ship service, an atmosphere of sulphuric acid, temperature variations in the region of 'scorchingly off-the-scale', etc. No, our difficulties in reaching our earthly destinations are because we do not start from the correct location.

This is a lesson I learned when lost in Dublin and forced to ask for directions. It was made clear to me that to get to point B I should have started at point A and not the point that I was currently at, which was currently unknown and would henceforth be referred to as X. Thus, making the logic more mathematically predictive.

The start point and the end point, part of the defining structure of a project and thus lifting it away from the realms of a simple action or activity, are critical in the initiation and definition of the project and the associated project plan. You will never reach the end destination if the start is left to serendipitous happenstances.

• Plan the beginning of your project meticulously
• Involve as many of the stakeholders as possible
• Hold a workshop with all the allocated resources
• Seek out Subject Matter Experts (SMEs)
• Do your research, technical, business, historical, etc
  
• Assess the Risks (qualitative and quantitative) and
  
• Look where you are going