'IT Project' Management Ramblings

Here a few comments on "IT" Projects. Some were learnt the hard way (and then learnt again and again).

Project Sponsorship

Do you have a sponsor? You Do? Great than everything will work out just fine (and I will win the lottery tomorrow). Are you sure you have the right sponsor? Not so sure anymore? Does the sponsor have the most to win or most to lose? If the project was assigned a project manager before agreeing on the sponsor then that’s a clue that the ride will be bumpy? If you don’t have the right sponsor try your best to change the sponsor. If you can’t then try to get someone else stuck with the project instead of you.

Project Length

Can the project be split-up? Nothing wrong with splitting it up. If you face resistance from people that don’t like splitting up projects give it a positive spin and start talking about a “program”, “roadmap” etc. maybe you can get them to accept your approach.

No, it’s not your Baby!

Don’t get attached to the project. Don’t get too excited about the technology you will get to implement. If you do then please go get a life! Be objective, be stiff. It’s OK to not even be convinced with the project’s value. You have to deliver the deliverables on time, budget and quality. The value is usually someone else’s problem (usually this secretive entity is called “the business”). On the other hand if it turns out that you are the one making the business case and promises of value that can only be realized by the business itself then you likely have setup yourself up to fail.

Project Team

Is everyone who will be assigned a significant task in this project part of the project team? Get them all into the team. They need to become part of “we” else they will be outsiders and you might get to regret that.

Commitment

Do you suspect someone will be a trouble maker? Every project has someone who isn’t convinced, is too busy, and has more important things to do. Expose them, assign them a task very early on in the project and act according to the results.

Dedication

If you project team isn’t dedicated to the project then you will constantly compete with others on the attention of your team members. They most likely have other responsibility that are more significant than your own project. Don’t forget that! Your resources will never give you the attention you expect (and they can’t since they are not dedicated to your project). You will need to follow-up not frequently but continuously to keep them on track and pull them back.

Planning

No project is too small not to plan for it. You only know that you need or don’t need a plan until you actually start developing one. Bare minimum you need a charter and schedule. Small projects usually turn out to be more problematic than you anticipate.

Eisenhower said “Plans are useless, planning is everything”. No plan is ever final until you achieve your goal. Assuming you don’t have either a crystal ball or a time machine then it’s OK to update the plan.

Failure

At the closure of the project we get to declare if it was successful or failed. If it failed, then it most likely did already early on. It’s just not easy to see failure early on. It’s like a parasite on your back, everyone can see it but not you. It will keep growing until it crashes you with its weight. When you acknowledge its existence it’s already too late. Don’t misread the signs, don’t keep hoping things will get better. They probably won’t if you don’t make changes that have impact and address the root causes of your problems.

2014 Security Predictions Compilation

I've put together a compilation of the 2014 Security Predictions I could find. You can download the Excel sheet here if you are interested. This tag cloud summarizes the result.

So what do security experts think will keep us busy in 2014?

1. Internet of Things: As if the onslaught of mobile devices wasn't enough to worry about, you will need to look after your fridge, TV, toaster etc. Will there be a patch Tuesday for LG or Samsung appliances? Not underestimating the threat, I don't believe it will be a major concern in 2014. My guess is that it's currently fashionable to talk about "Internet of things" and that's why it pops up so frequently. 

2. Mobile: Mobile threats are on top of the list. Business demands access to corporate services via mobile devices (It seems to be irrelevant which case has actual business value and which doesn't) and your job is to make sure that the demand (should we call it wishes?) is met in a secure matter.

3. Cloud: Cloud uptake might have taken a hit with the NSA revelations. I'm sure Mr. Snowden will keep us busy in 2014 with new revelations but nonetheless demand for the cloud will remain and so does the need to secure it. On one hand you have to work with the business units that resist the cloud due to some security concerns etc. and might be rejecting a valuable service due to a misunderstanding of the risks and on the other hand you have end users who want to make use of every possible cloud service irrespective of those 'made up' risks that IT keeps talking about. You are just keeping them from being productive, from collaborating and communicating etc. all those nice words that the business is unlikely to be actually measuring or attempting to measure.

4. Social Media Exploitation: Not as obvious as the previous points, but we've seen it coming. Criminals will make 'even' better use of social media in targeting their victims.

5. BYOD: It goes hand in hand with number two and three. Are we going to read about cases where BYOD went totally wrong and brought companies to it's knees for rushing into it? Nothing to worry about A dozen or so MDM vendors are lining up to give a helping hand with time proven solutions that quickly adapt to the changing mobile threat landscape (sprinkled with unicorn tears..) You probably will end up using a small subset of the controls that are "reasonable" to implement because your end users don't think it's that reasonable at all. You will probably end up making exceptions because some manager's device won't comply with your policy etc. Maybe another vendor can sell us a system for managing exceptions too?

So it's mostly more of the same, happy 2014!

References:

ISF’s top security threats for 2014

Georgia Institute of Technology: Emerging Cyber Threats Report 2014

Fortinet’s FortiGuard Labs Reveal Top 10 Threat Predictions for 2014

Network Utilities Systems: The Top Five Enterprise Security Threats for 2014 (and what to do about them)

Business News Daily: 7 Cybersecurity Risks for 2014

Palo Alto 2014 Predictions: Cyber Security Trends

Palo Alto 2014 Predictions: Mobile Security

Trend Micro Security Predictions for 2014 and Beyond

Credit Union Times: 5 Cyber Threats Coming at You in 2014

FireEye Top Security Predictions for 2014

Lancope's 2014 Security Predictions

Neohapsis 2014 Predictions

2014 Predictions from Symantec

Websense 2014 Security Predictions

Zscaler 2014 Security Cloud Forecast

5 Key Information security predictions for 2014 (Tarun Kaura, Technology Sales, India SAARC, Symantec)

Switching to Android

I've replaced my iPhone for a Galaxy Nexus. Mostly because I got bored with the iPhone and both my wife and I had to replace our phones because they stopped working correctly.

To summarize the experience: The Galaxy Nexus and Android have their flaws, but I don't miss the iPhone and I've no intention to return to it for now.

Here is my experience:

• Love the bigger screen.
• The back side of the phone gets hot when you use it for a while.
• The built in speaker is too weak. The iPhone's speaker is much better.
• Battery life is comparable to the the iPhone. Both need charging at the end of the day. For whatever reason my Nexus' batter life seems to have improved compared to when I first got it a few months ago.
• Love the widgets.
• Android Market region restrictions are stupid. I'm in the UAE and I can't even get some free Google stuff like Google Currents, have to search the net and find someone sharing the package file. Also am using the Amazon Appstore, but that's not an option for everyone since you need an US credit card.
• I didn't come across any application from my iPhone past that I missed on my Android. And I don't miss the billions of apps on the Itunes Appstore, even if they cost just a few dollars it's a waste of money and time to keep searching for the next cool app or deal you might miss.
• Like the ability to replace the keyboard. I installed SwiftX.
• When you hold the phone upright (portait) you get at the bottom three touch buttons. The one in the middle (Home) is just under the keyboard. Quite often I'm typing away and touch it instead of the space bar and ooops you are out of the app you were running. Annoying, but I'm getting better at avoiding it. In landscape mode you don't have that issue. Easily avoidable if they make the home button slight less sensitive when the keyboard is out.
• The autorotate is too slow for my taste, should be slightly faster.
• Camera is OK, obviously nowhere close to the iPhone 4s.
• Not sure how google is rolling out their updates, but I typically get an update two weeks after ppl in the US are already getting it (two updates so far).

I still have my iPad and I don't think I'll replace it.

FAIR Risk Management Taxonomy

The FAIR Risk Management methodology is impressive work. Even if you never are going to use it, I suggest you read it as it broadens your understanding of risk management.
A while back FAIR was handed over to the Open Group, I hope that will have positive effects and it will spread and develop further.


You can find it here.


I've mapped the taxonomy into a full map. It comes handy every now and then, just to remind my self of all the aspects that I need to consider when analyzing risks.

Click here for SVG Version.

Focus on the situation not the control types

We all know the three security control types: preventive, detective, corrective. When you are analyzing how to mitigate a risk you typically think about these three control types.

I find it more inutiative to focus on the stage of the event: pre-event, event, post-event. This way of addressing the problem creates context and leads faster to the identification of suitable controls.

Wikipedia maps the control types to the event stages like this:

Before the event, preventive controls are intended to prevent an incident from occurring e.g. by locking out unauthorized intruders;

During the event, detective controls are intended to identify and characterize an incident in progress e.g. by sounding the intruder alarm and alerting the security guards or police;

After the event, corrective controls are intended to limit the extent of any damage caused by the incident e.g. by recovering the organization to normal working status as efficiently as possible.

The only problem I have with that is the mapping of "During event, detective controls". When an event is occurring your only option of action is not just detective controls, you could also have additional "preventive" controls for example a worm is spreading in your network (event) and you are shaping your network traffic to slow it down or prevent it from spreading further. I suppose one could argue that you are preventing it from creating a new event, but that would be looking at the event as a series of isolated incidents which I believe would be countrproductive to looking it as one single event.

This approach has been known in the injury prevention field as the Haddon Matrix, which basically addresses the three stages but investigates them through different factors.

Interesting are also the possible ways to react in the three stages (reproduced below from Wikipedia), which is easily applicable to Information Security problems if you replace "agent" with "threat agent" and "host" with "asset".

Pre-event

1. Prevent the existence of the agent.
2. Prevent the release of the agent.
3. Separate the agent from the host.
4. Provide protection for the host.

Event

1. Minimize the amount of agent present.
2. Control the pattern of release of the agent to minimize damage.
3. Control the interaction between the agent and host to minimize damage.
4. Increase the resilience of the host.

Post-event

1. Provide a rapid treatment response for host.
2. Provide treatment and rehabilitation for the host.

If anyone has some good ideas how to apply the Haddon Matrix to information security and can suggest some factors to use, please share.

What's in a name?

Every now and then I hear that we are supposed to speak in the language of the business. In principle I agree to that, after all it's about communication and since we are the service provider and the business is the customer we have to fall back on the taxonomy they are using. But that's about it, don't exaggerate.


Take for example the service catalog, why would you refer to "E-Mail" as "Messaging Service" or "SAP" as "Enterprise Resource Planning" when for the past decade the customer has gotten used to these terms and is more confused by us trying to impose a perceived business language on them. My guess is that the user is perfectly OK with "Primavera" and probably confused if you suddenly start referring to it as "Enterprise Project Management". Maybe you can use those business terms in categorization, grouping etc. or in the service description but not necessarily in the service name if it's deviating from what business is really using on daily basis. 


The point is that we are not on a crusade to stomp out technical jargon if it's perfectly well understood and used by the business. IT is no longer alien and it's an integral part of everyday life. OMG and LOL are to be included in the the Oxford English Dictionary, the times have changed.


Don't loose focus of what the services are offering but don't necessarily brand them forcefully with supposedly business friendly terms.


And while we are talking about names, what were they smoking when they came up with "IT Infrastructure Library"? It's such a lousy name, it has no meaning at all. Every now and then I catch myself talking and referring to ITIL as if it were something self contained (that's the best word I could come up with to describe it). The goal of improved Service Management becomes an after thought and that stupid (forgive my 5 year old choice of words) ITIL moniker abstracts it and doesn't help.

Some thoughts about good metrics...

If you are like me then you must be facing some measurement challenges every now and then at work. There are some general rules that one needs to be aware of. Below is a short summary of some of those measurement rules, they mainly come from three sources that I highly recommend:

Doug Hubbard, How to measure anything, Finding the value of "intangibles" in Business 

Bob Lewis, Keep the Joint Running, A Manifesto for 21st Century Information Technology
Andrew Jaquith, Security Metrics: Replacing Fear, Uncertainty and Doubt 

 

Let's start with defining "Measurement". Doug Hubbard offers a simple definition for measurement "A set of observations that reduce uncertainty where the results is expressed as a quantity." (he looks at it as an information issue, read the book if that sounds interesting to you).

So basically if your observation is expressed as a quantity and you know after it more than you did before then we can call this observation a measurement.  The additional point here is that the benefit of the measurement should be higher than the cost of making the measurement; else it's not of much value. 

So what are the characteristics of good metrics?

• Complete and Relevant: Good metrics are connected to important goals. Good metrics are the translation of goals expressed in English to math. The measure must accurately cover your needs to be useful. In some cases you might need multiple measurements to support your business needs. One metric alone might not be sufficient for drawing conclusions and decision making. Also remember that everything changes; your once relevant metrics might not be as relevant in the future.  
• Consistent: Good metrics always go into on direction if things improve and the other if they deteriorate. The measure will always be the same no matter who carries out the measurement and records it. You can always count on the numbers. It's not a subjective exercise. If feasible the measurement should be automated.
• Expressed as a cardinal number or percentage, not with qualitative labels like “High”, “medium”, and “low”
• Expressed using at least one unit of measure, such as “defects”, “hours”, or “dollars”
• Communication: The results need to be communicated. Measurements are typically shared with others. It should be easily recognizable what the metric means. When the metric drops/rises to unexpected levels the source of the problem and the necessary actions are clear to your audience.
• Presentation: The presentation of measurements can be as important as the measurement itself. Spend some time on data visualization and always keep it simple.

One last tip, question conventional wisdom and metrics that are suggested by others to you. Validate them using the above rules. Every now and then you will come across a metric mentioned in a reputable source that just doesn’t stand the validation test.