I know I am making a rather bold statement with the 2.0 title connotation, but as Jurgen Appelo has effectively captured the Management 3.0 construct compared to 2.0 and 1.0, I believe a similar level of radical role change is occurring for information security professionals and specifically the CISO role within organizations. I’m finding I’m not alone in this thinking. Robb Reck over at InfoReck writes about the new challenges for CISO’s and also makes tepid reference to the 2.0 moniker. Additionally, Gartner’s Tom Sholtz makes similar assertions of the need for information security professionals to evolve to “truly understand how security links to an enterprise’s business goals” in a recent Bank Info Security interview.

The last decade in a nutshell from an information security perspective

The prior decade with the explosion of the information exchange and commerce via the Internet solidified the CISO role and the formal information security department as a critical need for any medium to large size corporate IT shop. As companies birthed whole new business models to leverage the seemingly endless financial opportunities the Internet afforded, the few IT roles that involved haphazardly securing “stuff” quickly were organizationally structured into information security departments. These departments were aligned separately within IT reporting to the Chief information Officer or in even more risk adverse industries and organizations, reporting into the Chief Risk Officer or other such non-IT role. Additionally, legislation and regulatory guidances were being passed to help address the abuses of weak corporate controls as well as rapidly expanding new Internet money movement and associated new fraud patterns. The list is extensive, but SOX, GLBA (technically passed in 1999 and probably more noted for reducing regulatory restrictions on US banks than prescribing security), HIPAA (again, technically passed in 1996), PCI DSS and FFIEC guidances are the first that come to my mind as impacting my information security career. While commerce was still rapidly expanding, at the same time, beginning the narrowing of frameworks towards technology standardization and commonly appreciated security controls, along comes Enterprise 2.0, as characterized by Andrew McAfee and the advent of social media’s dynamic change in people’s personal and professional interactions.

The need for information security investment and a strong, controls based CISO leadership focus was perceived critical. The need to keep the “bad guys” out of the company’s networks and data assets was ever in everyones’ minds. Asking for ever increasing budgets to buy and implement the latest firewalls, gateways, anti-virus, identity management and web access control technologies were made using the business case of fear of bad stuff happening and the seemingly well established security perspective that strong security controls protected one from data breaches and data loss. If a new business or technical initiative didn’t have a well known security control framework associated, security professionals, leveraging their unique position in the organization’s decision making hierarchy simply crushed the initiative with “no, we can’t do that, it is too risky”. Many a new idea was squelched with “security won’t approve that” motivated by a notion it was impossible to secure or a convenient excuse to avoid shaking up the status quo.

In all fairness, the last decade did go a long way to improve corporate and customer security technology controls. Where companies may have had internal security decisions made by disparate individuals across the organization, both inside and outside of IT, the formation of central security policies and standards and the subsequent evolution of centralized, risk based security decisioning was a major step forward. But, now in hindsight, a great fallacy has been realized:

Ever increasing investment in stronger and stronger security controls does not guarantee the elimination of breaches nor data loss occurrences.

As the last decade came to a close, the bad guys, struggling to directly attack hardened company networks and devices switched to the now clearly easier target: the company employees and customers directly. Phishing, being the early indicator of this switch in tactics, was most prevalent in financial services scenarios where access to an account holder’s on-line access permitted the direct movement of funds out of those accounts and into the fraudsters’ accounts. And thus, what John Kindervag of Forrester has labeled the need for “zero-trust” is one of the many signals as to the end of the prior decade’s strong control based “hard outer shell, soft gooey center” approach to corporate security.

The new decade brings the insider threat and Advanced Persistent Threat

With the start of the this decade, the success of security departments in the prior decade of hardening the perimeter has forced the bad guys to look for easier targets and thus why try to get through all those firewalls and demilitarized network zones when gaining access to customer credentials and employee computing devices gets you legitimate access to the data and transactions they desire. In parallel, the constant barrage of media coverage on successful insider breaches of major household names across all industries further sensitizes even the least technically inclined that bad guys are every where stealing everything. The rise of hacker brands such as Anonymous and Lulzsec further cements this information security breach fear in a wide audience.

Now, one would think all of this security press would be a boon to the security industry. For security vendors it truly is practically free advertising for the need for their products, at least initially. Vendors clamor to the table to insist they have the latest whiz bang tool that will protect your company from these evil hackers out to cause havoc and steal your data. But, with all this vendor and media fodder, the CISO conversation quickly has become much more complicated. Here is one particularly extreme example conversation between a CISO and senior management that over embellishes the problem to outline my point:

Senior Exec: I’m hearing about all these breaches. We are protected, right?

CISO: Well, not exactly. The bad guys are using new ways to attack and with the recent economic downturn, the company hasn’t been investing in protection as much.

Senior Exec: But we’ve been spending millions of dollars on this security stuff? Well, what do you suggest we do about it?

CISO: We should upgrade our FlimFlam protection technology, create more security network zones with more encrypting of stuff as well as hire more people to manage the security tools we have as well as start monitoring activity logs for suspicious behavior …

Senior Exec: So you are telling me we have to spend even more money and get more people to protect us? If we do all that can you guarantee we won’t get breached?

CISO: Well, even if we do all that I can’t guarantee we still won’t get breached.

Senior Exec: So what are you telling me to do? How much to spend? What is the worse case if we spend nothing? What if we cut back our current spend 10% or 20%? What would a breach cost for us?

Again, a somewhat far fetched example, but hopefully today’s thematic security challenge is more clear:

How much security is enough when one can’t guarantee, with all the security technology and best practices in place, breaches are still very possible, even likely, and the cost of breaches is difficult to quantify?

This is a different security paradigm today compared to last decade. Security professionals are coming to grips with the realization that, being a bit cavalier here, they were purveyors of a false sense of security in the prior decade with a “strong controls = strong protection = security” mantra.

If this weren’t enough, the continued Internet and Enterprise 2.0 evolution collides with the continued sophistication of consumer mobile devices. I even fell victim, although later than most of the technical gadget minded. The overtly intuitive touch-based, instant response user experience of the current mobile phone and tablet becomes a sharp contrast to the overly locked down, slow and seemingly cumbersome “legacy” experience with the corporate issued computing device. Even the once beloved device by corporate users and security professionals alike, the RIMM Backberry, quickly falls out of favor due to the conflict between a great end user consumer-focused experience compared to a locked down corporate experience. Security departments are now increasingly faced with:

Senior Exec: I want to get my company email on my iPhone without giving up all the personal things I already do on it.

The security roadblocks of “no, it isn’t secure” collide head on with “I want it now and they, they and them to are already doing it. You said we can be breached at any time no matter what controls are in place so why not?” The later being the most difficult to navigate given the reality of the current insider threat landscape. Plus, all the healthy discussion around why corporate laptops and Blackberries were locked down in the first place is eclipsing 10 or more years ago.

Even mobile device manufacturers are quick to respond by incrementally adding corporate security control options to their original consumer devices. Realizing the entirely “new” market for their products: companies with IT budgets, device manufactures are adding features to enable the open personal use while creating technical control barriers to corporate access and data within the same device. Thus, while RIMM’s Blackberry products are trying to make the evolution from corporate focus towards consumer focus, Google, Apple and others are trying to evolve from consumer to corporate. Both trying to achieve the best of both worlds leaving security professionals to try to stay abreast of all the dynamic changes.

The media has even labeled this whole spectrum of corporate mobile computing BYOD or “Bring Your Own Device”. With the IT punditry touting to security professionals: “it is not a case of if but when. BYOD is coming. Better get used to it.” Thus again, in this decade, saying “no, it is too risky or not secure” gets drowned out by senior execs wanting the more modern user experience backed by accountants saying: “if our employees can use their own devices to do work, we don’t have to buy each one of them a $3k+ company owned and managed device.” Any CIO would like to see the upside of reducing the IT budget by delivering an enhanced employee computing experience. How many times goes a CIO get to deliver something better for truly less cost? Yes, the cost/benefit economics of managing employee owned devices over corporate owned devices hasn’t fully be universally accepted. But, there is quite a bit of evidence to indicate it could very well be a windfall to get employees to bring their own computing capabilities to work.

So how does a CISO make the transition to 2.0?

Deep business integration

As primarily done in the last decade, focusing all energy on integration with IT technicians and integrating technical controls in order to secure business products, operations and services isn’t enough. At the same time, abandoning effective security process integration over technology initiatives will most certainly lead to control and ultimately security posture atrophy. A new balance needs to be struck between early business initiative engagement to offer security awareness to help integrate security into those engagements as they are gestated while maintaining a level of presence with technology delivery and change processes to ensure control strength doesn’t reduce.

Of course, this transition to business versus IT balance brings a host of yet to be fully answered questions:

Is the business ready for security professionals to be partners at the table against the prior perception of “security just says no to everything”?

Can security professionals be seen as credible through engaging business acumen?

Can security professionals accurately convey risk based decision trade-offs in easy to digest business language?

In closing, what keeps me drawn to the security profession is the constant changing landscape. I’m looking forward validating answers to these questions.

Do you agree or have I missed a major prospective here?

Produce a Business Case Deliverable

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

In the second part of this series, we used an example of engineer Bob recommending his company invest some cash and resources into an operating system upgrade. The initial logical conclusion that a sequence of facts surrounding how awesomely technically cool the new OS is would convince anyone to make the investment. Yet, spewing facts isn’t as compelling as it is to:

Relate the facts and figures to senior management’s goals/vision

To do this, structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the “Optimum” Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw anything ancillary or supporting to the above 4 steps in Appendices

In the Bob’s case, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Using the above sequence as a template for Bob:

1. Current State

• Number of servers running prior OS, server count over time
• CPU utilization
• Maintenance costs (total cost of ownership if it can be computed, support contract costs)
• Indicators when “bad news” like special support contract costs, etc. show “doing nothing” is a negative
• Intersection with any other projects that need capabilities provided by your Future State

2. Future State

• All servers running new OS phased in over timeliness
• CPU utilization
• Maintenance costs

3. Roadmap

• Upgrades broken into simple chunks
• Chunks representing some useful grouping (rather than random)
• Testing or other functions supporting the upgrade
• Costs over the duration

4. Next Steps

• $$$ approved to buy hardware
• $$$ approved for 2 resources
• Initial steps within your organization to get a formal project going

5. Appendices

• Data showing why 2 resources are needed, what happens if you get 1 or zero or 12
• Any other data, facts, figures around “hot button” issues that might come up like a trend to out-source or in-source work, strategic vendor partnerships, etc.

Your goal in telling this story is to have a compelling deliverable in the form of your presentation that conveys to anyone that it would be just plain silly not to execute your roadmap. That “anyone” needs to be both technical and non-technical people. I am certain your technical peers are going to be 110% behind anything that involves implementing new, cool technology. What techie holds the position of “nah, I still want to be a Windows 98 shop.” At the same time, the more holes that can be poked in your analysis the more likely your great idea is going to get trampled by the masses and not acted upon.

Sure, others might suggest not putting this much effort into a request that “should just stand on it’s own to support action”. A recent (how timely!) tweet from @rands suggests as such:

And although it might seem highly desirable to be able to convey your technical request in words and have immediate understanding and support, those veterans of large corporate IT shops know there is a big complex organization with overlapping, competing and sometimes contradicting priorities that can easily mount a campaign against your plan. Thus, those quick to dismiss the value of a slide deck deliverable in corporate IT might be missing a critical element of this series: producing a deliverable.

Sure, once you have a deliverable out there others can still mount a defensive. But, you also empower your management with a strong case to move in your direction that can be forwarded along and forwarded up. The more compelling your story, the more it stands on its own as a viable business case to make a strategic company investment the more the financial/business minded in IT will be able to comprehend and support your plan.

So, before you write-off the value of putting the effort into crafting a story deliverable that compels the non-technical decision makers to act on your plan, consider the alternative: a verbal request to spend money on some cool technology? If you are planning to invest a significant portion of your own money, do you want to buy some cool technology or act on a strategic technology investment with data backed returns?

Convincing senior management of technical direction requires new communications skills

As a server administrator, you invested in knowledge associated with configuring operating systems to perform optimally and be able to interrogate error logs to diagnose and report problems efficiently. As a software developer, you sought feedback from code reviews and combed forums and blog posts and (depending on when you were in this role) books to improve your code. In your role, you invested in the technical skills that expanded your ability to deliver solutions within your respective discipline.

Being measured on skill-set attainment wasn’t particularly evasive. Your servers were deployed live and they either performed their needed functions in support of applications and end users or they crashed after deployment with a flurry of functional issues reported to the helpdesk. Your code either met the functional requirements and was bug free after being tested or defect reports mounted. There was more direct feedback as to what skill-sets you have mastered and what areas of your respective discipline needed more investment.

Even communicating to your direct manager in these technical roles provided more instant feedback as to your ability to successfully articulate problems, issues and recommendations for improvements due to the frequent interactions between yourself and your manager. And from your manager’s perspective, they were tasked with delivering a service and needed you to execute tasks to meet commitments.

But what about communicating to senior management?

In most cases, you are not directly interacting with senior management on a daily or even frequent enough basis to build implicit trust. You can rarely walk blindly into a budget meeting with senior management and say:

“We need to upgrade all the servers to RHEL 6. In order to do that we will need to buy ten new servers at X dollars each for a total of Y dollars now and we will need two more people to build and swap in all those servers. Of course, we’ll need all the applications to test after each server is re-built. And …”

with senior management responding with:

“Sure Bob, let me get out the checkbook …”

It is almost painful to observe a solid, technical individual attempt to explain a technology need to senior management who hasn’t determined how to effectively communicate that need in a format that senior management can more readily absorb. Equally troubling is seeing a poorly communicated yet real technical need be decided against by senior management based on a weak presentation. You can almost predict the conversation that will happen some number of months later:

“Bob, how come we have to pay this huge support contract on our servers? How come I didn’t know about this earlier?”

“But Sir, I tried to tell you we needed to upgrade our servers before …” This conversation becomes more awkward with each subsequent exchange.

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

So, what steps can one take to make this investment in their communication skills? For one who has focused on learning technology, the shift of focus to learning effective communication skills may seem elusive at first. Thus, consider spinning up a thread in your brain that breaks this down into a logical exercise.

Look for part 2 of this article to dive into some logical steps.

A Single View of the Work is a powerful management capability

Well, what started back in mid 2009 as a few blog posts to capture a systematic approach to trying to get a handle on the various ways work requests come to a delivery focused team exploded into a 14,000 word, 13 part blog posting series on the topic. I managed three different delivery teams within three different companies within three different industries while this topic was being explored. The diversity of the teams, the size of the overall organizations (6 member team in 2,000 person IT department within 36,000 employees, 21 member team in 40 IT person department within 300 employees and 8 member team in 100 IT person department within 7,000 employees) and the industries (financial services, legal services and manufacturing) all helped to give me confidence to present the model described throughout this series.

Clearly the theme throughout this series is to use data where ever possible to represent all facets of the work your team is doing. In all three companies I received extremely positive feedback for the effectiveness of my approach from my management. Thus, I felt confident to share my approach with others in hopes others would find a way to adopt some of the techniques to enhance their management function.

Below is a brief summary of the key take-aways and techniques presented in each of the parts of this series in case readers missed any parts along the way or are interested in reading more about a particular topic:

Part 1

Starts the series by requesting you make a list of all the high level service delivery attributes of your team. Next, you are asked to list out the various ways work arrives to your team for each attribute that was documented. Additionally, if there was specific technology under the umbrella of services your team provides, document those and include relevant dates of version upgrades and version end-of-life conditions that represents work you know your team has to perform.

Part 2

Part 2 extends the list in part 1 to start to derive a model for how your team operates. You are asked to identify how much influence you have over each work attribute. Those attributes of which you have a high degree of influence means you are in a position to plan out the work. Those of which you have little influence means you are reacting to the work. For the attributes with little to no influence, you are requested to identify sources of predictive data such as historical request metrics and duration data to form trends. Additionally, you are asked to develop relationships with individuals and groups that are sources of work requests to assist in building work request pipelines.

Part 3

Now that a baseline work request attribute and influence system has formed, you are guided through the thought process of determining how much capacity your team has to actually deliver work. The familiar topic of an eight hour day doesn’t really mean each team member can focus eight hours on work requests is discussed to arrive at a data supported, more realistic number of hours per day to dedicate to service request work.

Part 4

Part 4 describes how to apply the numbers your collected in part 3 towards juggling high and low influences over the requested work scheduling. How to communicate this juggling by using data to your management and work requesters is also discussed.

Part 5

This part in the series describes how to take the low level numbers from the previous two parts and determine the true overall capacity your team has for doing work in a given time period. The excellent article on this pragmatic capacity planning by Peter Kretzman (http://peterkretzman.com) is also covered.

Part 6

Part 6 dives deeper into work requests that require some partial dedication of a resource on your team to a work effort and some of the nuances around safely committing to work deliverables knowing you don’t have fully dedicated resources.

Part 7

This part talks about how to integrate unplanned work requests into in flight work at a high level. Engagement models and other similar topics are also discussed.

Part 8

Now that the basics have been covered and a variety of work request patterns have been discussed, this part starts to walk you through how to build a comprehensive team resource plan.

Part 9

With Part 8 setting the framework for your team resource plan, Part 9 suggests how to sequence and represent detailed work requests. Additionally, having your team participate in the process as well as provide critical work estimation data is also covered.

Part 10

Now that the team resource plan has the majority of externally requested work represented, the addition of non-request work is covered. Topics such as “special projects” and “HR-ish” work is covered. What to include, what to not include and to what level of detail is the focus of this part.

Part 11

Now that you have a rather comprehensive team resource plan, this part describes mechanisms to help keep the plan from going stale. Additionally, how the plan improves your external perception as a manager is explored.

Part 12

This part extends your team resource plan to offer “what if” scenarios around the cost of working on a new hot priority request and how to use your team resource plan to assist with prioritization with your management and the requesters.

Part 13

This final part tackles one of the most challenging topics facing a team manager: how to justify a request for additional staff. The team resource plan is a critical tool in either forecasting forward or re-planning the past to use data to justify that staff add.

All in all, I hope you have enjoyed reading this series and found some element of it useful to you. I would appreciate any comments on the series as whole as far as its overall usefulness to you as well as any feedback around alternative approaches to topics I’ve outlined.

Focus on data to justify more staff

As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly unpredictable requests for work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.

In the first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, I described a few “what if” scenarios around handling competing priorities. This article will offer additional “what if” opportunities your plan enables you to explore surrounding team staffing levels.

“What If” Opportunities – Adding Another Team Member

Another extremely helpful “what if” opportunity is to show, with data, what adding another resource to the team would mean work delivery-wise. Every organization has a less than scientific way to permit team managers to establish business cases to justify adding more staff. Without data, a manager is left with less than optimal hunch based or eloquent prose based means of communicating the need. Now, with your sophisticated team source plan, you can either project forward or go back and re-plan history.

Project Forward – Strong Pipeline

If you have a more mature organization when it comes to planning you may very well have access to data that indicates what work your team will be tapped to do in some capacity in the coming year. This data will help you in presenting data to support your request for additional team members. Don’t fear if your organization doesn’t capture future work very effectively. The next section “Weak Pipeline” will help in that situation.

Create a copy of your resource plan and begin to add the projects and work requests listed for the coming year. Make some gross estimates as to your team’s involvement. Yes, there is indeed an art to these estimates. Involving your team members in this next year forecasting of work exercise will help to give you additional perspective as well as implicitly implicates your team members in the estimates themselves. I don’t suggest you go so far as break out your estimation templates and spend hours upon hours defining and estimating all possible details related to the future work. Rather, assigning big buckets of hours to “small”, “medium”, “large” and “mega-huge” work blobs is quite enough. Remember, your audience is your management team not the business requesters that will grasp feverishly at any dates available to them no matter how hastily concocted on a bar napkin. Thus, general estimates that can be plausibly linked to known work is more effective in achieving management buy in than overly detailed analysis.

Senior Management: “Upgrading FlimFlam next year is twice as much work as the FlimFlam disaster recovery project this year? Twice the planning? Full regression testing? Go live involves keeping the old version operational until all end users are cut over to the new version? Ok, twice as much work makes sense.”

Once you have the list of projects, using your new copy of your resource plan, start plugging in the project details using your current staff count. Next, make another copy of this future projected plan and look for skill set constraints and/or work completion dates that you know senior management isn’t going to be pleased to see. Add in hypothetical new hires with skill sets that significantly increase your ability to show a resource plan that accomplishes more work in less time. You might be surprised to see that the skill set you think you need isn’t as important as another skill set of which you figured you had plenty of capacity.

Re-plan History – Weak Pipeline

If you don’t have a strong work load pipeline outlined for the coming year, don’t give up hope. Take a copy of your resource plan from the previous year and look for where you had resource contention. Pretend you could wave a magic wand and have had additional resources join your team with those contended skill sets. Add in the number of team members you are asking for in the next fiscal/budget cycle year. Show a new plan from the previous year that indicates how much additional work your team would have accomplished given the addition of more staff. Your argument is that if you had these additional people last year, your team would have accomplished all this additional work. If next year looks to be even more work than last year then more staff is critical.

Next Steps – Weak or Strong Pipeline

Having a pipeline of new work for the coming year is a bit more powerful to present compared to re-planning  past year. But re-planning the past year is better than having no pipeline and throwing your hands up in despair and whining you need more staff] (external link to blog.brodzinski.com).

Pulling it Together

Lastly, consider adding some fudge factor for unplanned work that you know always pops up every year. One way to project forward for the unknown is to look back over the previous year and note all of the work that appeared out of no where. If you can articulate how you arrived at a percentage of unplanned versus planned work, you can apply that percentage to your next year plan. Make sure you can confidently explain how you derived that unplanned estimate that is based on a guess based on a whim. If you don’t feel confident you can stand behind your guess at unplanned work, don’t add it explicitly to your plan. Rather, just verbalize the plan you are presenting assumes there is no additional work hitting your team next year than what is already known. This conservatism will help offset any weaknesses in your existing projections. I’ve found that if you go into a meeting with senior management asking for additional staff and you have wild guesses based on wild guesses in your data, the value of the data diminishes to the point that senior management begins to lose confidence in your pitch overall for more staff. Rebuilding that confidence can be insurmountable.

Now, with more confidence based on your new plans, meet with senior management to share your reports:

Manager: “Looking forward to next year, I took the next budget year project pipeline data and based on currently known request scope, projected out work for next year based on my current team and their skill sets. What concerns me is that with all the business projects and their early start dates, the FlimFlam upgrade project looks like it can’t finish any earlier than the end of Q3. With Sally and Bob in demand on those business projects as well as the upgrade project, by adding another team member in early Q1, it allows the new team member to pick up some of those less complex business projects. This frees up Bob and Sally, and as I am showing on this alternative team resource plan, the FlimFlam upgrade project can start as early as late Q1. Thus, realistically the upgrade could be completed by end of Q2 rather than Q3. Additionally, these other business projects would complete months earlier as well since Bob and Sally can’t work on more than two projects at a time before quality is so poor and thrashing stresses commitment dates. That additional team member can significantly smooth out the spike in that skill set need for next year. Plus, we both know Sally and Bob have been in demand the last two years with work having to be scheduled around their commitments …”

With data in hand, this conversation is much more fact based compared to “I need more people because my gut says so.”

If you ultimately don’t get your staff add don’t be completely discouraged and give up on using your resource plan as a forecasting “what if” tool. If you’ve laid out the next year of work to your boss without the granting of additional FTE and people start complaining about your resources not being as available as they desire, you can take comfort that you made your boss aware. Thus, when his or her phone rings with people complaining because you can’t meet their needs, he or she shouldn’t be surprised. By presenting your boss with plausible data that he or she can’t support with more staff implicitly holds your boss accountable and you a bit less for the service availability complaints. Of course, you need to constantly look for ways to squeeze as much efficiency out of your resources and processes as possible. You don’t get a free pass as a manager to goof off just because your boss didn’t immediately provide you a new hire opportunity given your masterpiece of work load projections.

Additional “What Ifs”

There are certainly more “what if” possibilities you can do with your team resource plan. It can be very effective at communicating commitment deliverables and dates to project managers. It can help clearly articulate the schedule impacts related to multiple approaches to completing different goals within a project. “Adhering strictly to the architecture and delivery guidelines, these blobs of work look to start and end according to plan X. Being permitted to deviate from these specific delivery guidelines allows these blobs of work to be starting and ending according to plan Y.” It can help show what the impact is for doing certain tasks before other tasks to help others prioritize requests. There are many benefits to creating and maintaining a team resource plan. The next article will summarize all of the main points captured in this 13 part series of a structured team management strategy entitled “Single View of the Work”.

Drop everything and make project "X" the top priority!

As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly unpredictable requests for work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.

In the first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, I described how to keep your plan from going stale as well as the benefits to you as a manager for making resource plan a prominent source of data in all your delivery commitment discussions. This article will offer various “what if” opportunities your plan enables you to explore.

“What If” Opportunities – Drop Everything and Work on X

After all the work up till this point in building and maintaining your plan, here is where you can experience some real power of your team resource plan actually making your life easier. Consider this incredibly typical work scenario:

Senior Manager: The VP of Operations just told me the new FlimFlam upgrade project needs to start immediately and is now the most important project for everyone in the department to be working on.

Manager: No problem. Upgrading FlimFlam requires my team members Bob and Sally to be engaged to make system changes. I’ll let them know the new priority and I’ll communicate to the requesters/sponsors of what they are presently working on that their requests have been bumped in priority.

<Conversation continues>

During this conversation, by getting out your resource plan, you can easily identify what work Bob and Sally are presently engaged. You can share with your senior manager the impact of the priority change he or she is mandating. Before we go too far, there are some subtleties to this specifically structured response that I would like to call out:

1. You aren’t saying “No”.

Clearly, your manager is making a demand not asking a question. Thus, saying “No” isn’t an option just because it causes massive changes to your brilliantly crafted resource plan. There might be situations where telling your manager “No” is the right response, but I believe the majority of situations are best handled without a direct “No” as the immediate answer.

2. While agreeing, you are sharing the “cost” or impact of the shift in priority.

In a polite manner, you are agreeing to the request. But at the same time, you are sharing the “cost” or impact of what current work in flight will be paused and thus delayed as resources are shifted. In a non-threatening and non-confrontational way you are allowing your manager to get an appreciation for what work he or she is implicitly approving can be delayed. This subtle phrasing also allows your manager to consider if the “drop everything and work on X” is truly that important. You have allowed your manager to save face and possibly engage in a more detailed dialog around how to slot this new work in with existing work. In general, allowing your manager, the individual with the most direct impact on your paycheck, to save face and achieve their objectives as often as possible is always a good thing.

“What If” Opportunities – “Cost” of Working on Y

Another “what if” scenario that your resource plan can help you with is assessing the impact of asking resources to work on side or “special projects”. As an example, many times during the year pops up the potential need to know what features a new version of a system provides compared to the current. Another example would be a new technical capability that sounds on the surface to benefit your team but someone needs to dig into it to determine how much real benefit. Yet another involving software development teams is re-factoring existing code because what was put in production works, but really needs to be changed to meet standards/guidelines/ enterprise re-usability, etc. If your team is delivery focused, everyone is probably fully allocated to business work according to your plan thus asking anyone to put some time into a “special project” is going to add stress to that individual’s ability to meet their committed delivery dates.

Your resource plan gives you the ability to consider the impact of, say, adding some number of hours per week to a particular team member’s workload. There might exist enough slack time on a particular assignment within a project or work request to absorb those additional hours. If not, there might be the opportunity to contact the work requester and confirm that extending the delivery date by a few days is acceptable. Alternatively, you can schedule a few days/weeks of contiguous time after a delivery date for a particular resource to be dedicated to the “special project”. This way, you can work the “special project” assignment into that resource’s normal workload and delay uncommitted additional work items until the task is complete. This effectively treats the “special project” just like any other work request or project task forcing other tasks to be schedule around it. This gives you the ability to time box the “special project” with your team member so they can focus on this work without distraction as well as give them a clear end date when they need to have their work completed.

At this point, you have a few “what if” scenarios attributed to your team resource plan. In the next article, I’ll suggest more “what if” opportunities your resource plan possesses particularly around staff leveling.

How credible are you perceived?

As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly unpredictable requests for work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.

In the first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we finalized our Gantt chart listing all the external and internal work requests. We also added “HR-ish” activities and other categories of work that can impact delivery. This article will offer considerations on how to keep the data from becoming stale and how the plan benefits you as a manager.

Avoid Going Stale

Like any resource plan, it is only as accurate as the last time it was updated. You have put plenty of work up till this point in building your resource plan; don’t let it get stale. Consider making reviewing and updating the report a fixed agenda item for all one on ones and possibly some full team meetings. By sharing together with your full team you help team members get a sense of what others are working on. You never know one when team member will notice what someone else is working on and be able to offer some advice or alternative points to consider. If you are managing towards fostering a more self-organizing, self-directed team, which I’ve written about prior, this technique of sharing the resource plan with the entire team helps to communicate the broader workload. By encouraging team members to offer opinions and share perspectives on what others are working on organically moves your team towards more self-direction.

When it comes to updating your plan, to reduce the burden of taking notes then going back and updating the chart, consider updating the chart in real time with each of your team members. The real time update not only saves the burden of taking good notes and having good memory recall, it allows for immediate feedback and verification during your one on ones. Placing a copy of the report in a shared location for your team to view and update is great, but the additional value of making and talking through updates in real time can be exceedingly more valuable. Again, this is another opportunity to increase team member engagement through actively discussing what they are working on and capturing it in the plan.

Depending on your management style, the frequent real time update of the chart during one on ones could replace the classic weekly status report.

Management Perception Benefits

Now that you have an accurate and professional looking report of what work your team is doing, start to carry a paper copy around with you every where you go. Try and print out a copy of your most recent update on a large, single sheet of paper. Print a new copy after every major revision and discard the old copy. If it doesn’t appear clearly on the report, write the date of the latest revision. Consider setting a date range for the report of:

• Go back about one calendar week from the present date or the date you are printing.

This helps you answer questions pertaining to what transpired last week that impacts future projections. This is handy to be able to quickly respond to queries with: “Last week Sally was sick for two days and that is why her deliverable carried over into this week.”

• Report out a few months. Consider three months maximum.

Depending on the level of priority changes and work request adds/changes, you will probably discover that reporting out into the distant future isn’t all that helpful. Consider starting with three months and see how often you are discussing work requests that far in the future. The smaller your organization, more than likely, the shorter the future can be predicted. In truth, the level of maturity in work prioritization and forecasting in your organization will impact the frequency of report changes and the ability to project far into the future. The more mature the more consistent data available to reduce the frequency of changes to your plan. The less mature and more prone to “IT Instant Gratification” the more frequently you will be forced to re-juggle your resource plan.

By carrying around your plan and frequently referencing it in meetings, discussions, etc. you should notice a significant up tick in your external perceived management capabilities. Really? How so?

• Increase in perception of knowing what is going on

Sure, you might be able to keep everything you and your team is involved in at any given moment in time in your head. What is more likely the reality is:

As more and more work is being dump on you and your team, your brain is bound to get overwhelmed and loose details.

Thus, having a detailed report at your fingertips helps jog your memory reducing the chance you might miss something important in a discussion. Plus, when pressured to commit to deliverable dates, and what project manager doesn’t want you to commit to a magic date on the spot, you now have a legitimate excuse to pause, look at your plan, and then offer a more thought out response. Sometimes just the ability to inject a break in the pressure of the commitment exchange permits avoiding that hastily, in the moment, less than optimal reply.

• Increase in the credibility of your resource communications

Without report: “Bob is working on X now and should be done by Friday.”

With Report: Reviewing report prior to responding “Bob is working on X now and should be done by Friday.”

You are sharing the same message and very well could be using the exact same words in both cases. But, when you visibly reference some data prior to making your statement, your words are augmented with an increased incredibility. I attribute that increase to the external perception of being on top of what is going on and having data to support your statements that your resource plan gives you. Others don’t have any competing data, thus you have the more authoritative position in the conversation. The folks at Thinkshift Communications have developed a Credibility Quotient as a formal criteria for determining the level of credibility in one’s communications. As a factor in their ranking system, they specifically call out “Providing support for claims is the most important single contributor to credibility”. Sure, the corporate bureaucrats and smooth talking management pundits are able to talk circles around why something should be or needs to be delivered by a certain date. You can challenge back with equally crafted responses alone or remove the emotion and let data in your plan drive the discussion.

• Benefit of your responses having higher “stickiness”

The increase in the perception of you knowing what is going on and the resulting credibility in your responses nets you the benefit of having high “stickiness” in your responses. You will notice, especially in people that challenge your resource assignment or contention concerns, that over time you will see a dramatic drop off in the frequency and aggressiveness of challenges to your message. I directly attribute this increase in people taking you at what you say (rather than immediately challenging you) to the resource plan’s increase in your credibility.

At this point, you should have an accurate team resource plan that you have incorporated into your management work delivery commitment interaction discussions. In the next article, I’ll describe the additional power your resource plan possesses through it’s “what if” capabilities.

Consider tracking team member vacations on your resource plan

As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly unpredictable requests for work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.

In the first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we finalized our Gantt chart listing all the work requests and projects by work phase and indicated which team member is work on which phase with durations and dependencies from your team’s estimation sheets. Additionally, your team review of the chart increased its accuracy and improved your team’s level of engagement again. This article will offer considerations on what additional, non-external work to reflect on the chart for improved reporting.

HR-ish Stuff

The first non-external work data items to consider adding to the team resource plan are company holidays, mandatory “all hands” meetings and team member vacations. Basically, consider adding all the HR-ish stuff that requires your team’s time that results in the loss of the ability to work on other “real” activities. You may want to establish a threshold for the duration of HR-ish stuff to add. You may recall we calculated a real work day of five or six hours assuming 1:1’s, fire drills, performance reviews and other interruptions previously. Thus, you may want to consider a minimum threshold of a full business day. A single hour one on one still allows a team member to complete a task on that same day. Contrarily, a full day off-site “all hands” meeting does not permit any “real” work to get accomplished on the day the meeting is scheduled. Thus, creating a break in the work all team members are performing on that specific “all hands” meeting day reflects the real world impact of such events on your team’s estimates and work delivery. Once added, all work delivery end dates should be pushed out a full day. In my experience, when estimating work, technical people rarely think through the impact of such business event. They don’t always realize the need to incorporate these events into their work delivery communications and expectations setting.

Vacations

Adding team member vacations is extremely helpful from multiple perspectives. For one, it is a great single place for you to keep that information. Your company may already have an HR administrative system that automates the process of keeping track of this information thus this benefit might be marginalized. But if you aren’t fortunate to have such a system, it can become a real hassle maintaining and updating a spreadsheet to track this information yourself. By incorporating this administrivia into your Gantt chart, keeping track becomes just another step in the process of keeping the chart data updated through team one on one discussions, etc. For our planning effort, the lager benefit for tracking such information is in the improved accuracy of establishing work request delivery end dates. If another 40 hours is needed for a team member to complete a specific work request but that team member is going to be out on vacation for the next five days, clearly that work request isn’t going to get completed for at least two weeks. By adding that team member’s five day vacation as a break in their work on that request, the new work delivery date now is more realistic. With this vacation break clearly noted in your chart, external parties have a clearer picture on what is making the request take, in this case, at least two weeks minimum instead of expecting the request to be completed next Friday.

In summary, consider a threshold of a day for HR-ish work events and the following activities to be worthy of explicit Gantt chart reporting as material breaks to in-flight work:

• Vacations
• “All hands” meetings
• Off-site meetings (even if they are half days, consider the travel, etc.)
• Training sessions (full day and/or off-site)
• Sick days

Recording sick days can be really handy when a team member misses a few days of work and the ability for them to still complete their work request on the originally estimated completion date is infeasible. Additionally, as the weeks go by it becomes increasingly difficult to remember such loss of work days occurring in the past. This data can be critical to have captured and clearly reported on over time when the delivery date is fast approaching and requestors are starting to challenge the status of the work request progress or perceived lack of progress.

Special Assignments

Another body of work that deserves reporting recognition is the special assignment. From the typical situation:

Manager: Hey, can you look into what systems will be impacted when we start the FlimFlam upgrade project and let me know by next Friday before the quarterly project review meeting?

Team Member: Sure.

You asked that team member to do that work because it is important for your meeting. Now adding that request as a new single Gantt row of work accomplishes a number of goals:

• Records the request so both you and the team member know it was made and when it is due.
• Reflects that request along side the other work that team member is actively working on.
• Communicates to other team members what each other are working on beyond just formal request and project work.
• Communicates to outside parties all the work required by your team to perform the services they are charged with beyond just the formal request and project work.

In the act of recording the request you might (hypothetically) notice that the team member has a critical work deliverable due that same Friday. You have the opportunity to follow-up with that team member to remind them of their deliverable due dates, reset priorities or re-assign the request to another team member.

Again, you will need to develop your effective level of detail in reporting these non-external work requests. Your goal should be to strike a balance between overly detailed and thus time consuming to track compared to too little detail and thus requests get missed or lack external visibility.

On Going Assignments

You may want to consider adding on going assignments that don’t have a true end date to your report as well. An example might be investigating a new technology in order to consider its use in solving a formal work request in the future. I would suggest you put them at the very bottom of your report since they won’t change frequently. You may want to consider coming up with a unique color for these never ending requests. Since the time applied to these assignments varies, I wouldn’t try and update any work estimate durations around them unless you really want to enforce a team goal. A goal such as “spend 10% of your time investigating new technologies” should involve the reduction in about a half a day per week applied to all work estimates. This overall reduction formally allocates time for all to accomplish this goal from a work estimation perspective. Motivating your team members to meet their pressing external work deliverable dates plus invest time in learning new technologies at the same time is another matter.

At this point, you should have an even more accurate team resource plan reflected in your Gantt chart including all the major external and internal work items your team is engaged on. In the next article, I’ll suggest ways to keep the report from going stale and examples of the power of your resource plan possesses in improving how your are perceived as a manager in your organization.

Building structure without command and control ... isn't that an oxymoron?

I can’t say enough positive things about the stimulating agile management views shared in Jurgen Appelo’s new Management 3.0:Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn)) book currently available here on Amazon.  Jurgen has assembled an extremely thought provoking text that covers the breath of the challenges to effective team management today.  From the basics of self-organization to leading people to effective communication to competing management models, Jurgen has provided chapter after chapter of excellent insight into what is needed to manage in today’s dynamic business climate.  Even though I could go on and on about my interpretation of each chapter, this article will focus on one aspect of Jurgen’s “Martie the management model” depicted in the below graphic and introduced in Chapter 16 labeled “grow structure”.

Even though my background is focused on working in corporate IT departments rather than tech startups or consulting, I found great validity in Jurgen’s “views” outlined in his management model including his own admission that it is “wrong” (p.371) to some degree as all models are inherently wrong in being comprehensive and time proven.  Some may say that corporate IT and in particular, large corporate IT departments are unable to be “agile” and thus such an agile management model is less relevant.  I disagree in that there is a constant barrage of blog articles and news stories pressuring corporate IT to be more nimble, deliver more value quicker and with less people.  Thus, managing less people who are expected to wear even more role and functional “hats” requires a more progressive management style compared to the more traditional command and control approach.

With all that being said, wouldn’t one conclude that to “grow structure” one would have to invest in even more command and control management techniques?  Quite the opposite is proposed in Jurgen’s model.  Covered in depth in chapter 13, Jurgen suggests that in order to be in a position to efficiently adjust to the changing demands of the overall organization, technology, products and people, a manager must institute concepts he identifies as “generalizing specialists, wide job titles and informal leadership” as summarized on page 309.  I interpret, from a corporate IT perspective, the structure he is proposing to be one of recognizing the multiple hats and positioning the team to best adapt to change.  Examples in my mind include working with that technical expert in one narrowly defined domain to assist them in appreciating the need for expanding outside of their discrete technical silo through coaching, mentoring and stretch assignments.  Additionally, challenging team members that have been previously placed in narrow job definitions to think of delivering more expansively; while at the same time, providing some structure to that expansiveness in order to provide a level of focus so team members can actual accomplish a task or function.

So, implement wide job titles, push team members to take the lead on assignments (informal leadership) and stretch specialists to become generalists … this doesn’t sound like creating structure?  I encourage you to pick up a copy of Jurgen’s book and explore how he eloquently presents a compelling argument for why such destruction of traditional command and control management is most effective in being an effective manager and leader in today’s business climate.

SAML 2.0 is King of Federation Standards

For the next three days I’ll be attending the Gartner Identity and Access Management Summit.  I’ll post a daily summary of the sessions I’ve attended.  If any of the sessions have something particularly noteworthy, I’ll relay those interesting items via Twitter.

Day 2 was a quest for more customer stories and testimonials.  But the opening session by Chris Hansen, correspondent for the NBC News “Dateline NBC” program was riveting.  Hands down it was the fastest 45 minutes of the entire conference.  Chris had a way of sharing the behind the scenes stories that lead up to the final “To Catch a Predator” specials that really had the audience hanging on his every word.  I recall the promotions for the show but I never actually watched the show itself.  The gist is an NBC investigative reporting team, lead by Hansen, pose as a 13 or 14 year old boy or girl online and attract predators to a house for inappropriate encounters.  The house is wired with microphones and hidden cameras.  The predator arrives and Hansen confronts the individuals about their illegal behavior.

One of the most disturbing comments Hansen shares is that he felt if they picked any city in the US, his team could setup their operation and within 24 hours, have 50 people lined up wanting to participate in illegal behavior.  He mentioned he had doctors, firemen, clergy, businessmen … non-stereotypical people all looking to take advantage of children online.

Hansen linked his investigative team’s methodology to being successful with attracting pedophiles, electronics fraud, terrorist cells, you name it.  It was a bit concerning on how the strong can take advantage of the weak online and it is very challenging for law enforcement to thwart such attacks.

It sounds like a very negative topic, but Hansen did an excellent job of communicating the seriousness of his experiences along with humor and a pragmatism that left the listeners with a deeper appreciation for the work his journalistic team dedicates to such endeavors.

Back to the quest for more customer stories and testimonials

I didn’t find the remaining morning sessions communicating anything I didn’t already know.  It wasn’t until the post lunch session on “Managing Identity in the Cloud” by Gregg Kreizman that I found something noteworthy.  With all the buzz around cloud computing these days, I figured this would be a popular session and I wasn’t disappointed.  With multiple concurrent sessions, I would venture a guess this one had the bulk of attendees compared to other sessions in the same timeslot.  Without further delay, below are my bulleted notes from this session:

• Web Access Management and Identity Management are precursors for SaaS/Cloud solutions for your business.
• Make sure to get Identity and Access Management (IAM) provisions into your contracts and terms and conditions with cloud providers.
• Federation was slow to start, but it is growing strong at present, kicked into high gear with companies looking to leverage cloud solutions.
• Cloud vendors are offering federation support, even though this presents an easier path to customer switching (reduced customer “stickiness”), because customers are demanding it.

I finally was hoping to hear some good customer insight at the “Road to Success is Paved in Strategy” session with a senior manager of global security at Mattel.  It was a well constructed session on IAM strategy, but nothing radically different than the textbook approach to introducing a new technology and/or security discipline in a large organization, namely:

• Implement IAM as a 3 to 4 year initiative
• Have a focused PMO around IAM
• Mattel chose to focus a dedicated PMO resource, a business analyst and a systems analyst to IAM
• Prioritize applications (don’t boil the ocean)
• Get senior level champion outside of IT
• Cast a wide net with stakeholders, application owners
• Don’t just focus on technology
• Stay focused on business goals and objectives
• Focus on quick wins
• IAM can be painful so don’t expect an easy road, especially if you buy tools first
• Get some outside industry help

Lastly, it seems “New Directions in Federation” has confirmed what I was sensing since first embarking on federation a handful of years ago: SAML 2.0 is emerging as the clear winner amongst the various competing standards.  Federated authorization is another story.  No clear choice amongst the emerging standards morass.

Thus, let me be the first to pitch “Hillbilly Federated Authorization via SAML 2.0”

• In the SAML 2.0 payload on a federated sign-on, in addition to providing the required authentication information, use the <saml:AttributeStatement> element to include the identity provider’s user specific authorizations for the partner’s application.
• In addition, add “auto-provisioning” where all of the attributes needed for your authenticated user to be setup in the partner application is provided in every SAML assertion.
• Couple “Hillbilly Federated Authorization” with “Auto-provisioning” and one has a very light weight and company controlled extended/federated authentication and authorization model.

Where does this break down? Well, for one, if your federation partner is unwilling to work with you on this hybrid solution.  And second, if you have a significant number of authorizations (fine grained entitlements), then trying to duplicate those in your directory plus add an administrative UI to manage those directory attributes PLUS keep everything in sync with every partner major/minor application upgrade … I think there will be plenty to talk about Federation at #GartnerIAM 2011.