Midwest IT Survival

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.

Gartner Security and Risk Summit 2011 - Day 4

I am currently attending the Gartner Security and Risk Management Summit 2011. As the final day drew to a close, the sessions didn’t carry significant new material and the ones I was interested in tended to be a bit vendor sponsorship heavy. I blogged about day 1 here, day 2 here and day 3 here. I always enjoy the time away from the cubical to allow ones brain to focus with minimum distraction on the topics being presented at such conferences. Below are some of the tidbits of knowledge I captured from the fourth and final day.

The most noteworthy event that occurred on the final day was a conversation over coffee between myself, a senior security manager at Microsoft and a new to his role security manager at SC Johnson. They both shared that their security teams are getting an increase in funding and FTEs. But what I found most interesting was they each were adding security focused developers and engineers to their teams in reaction to shifting from pure security governance to security governance plus technical delivery. They each mentioned that they were now starting to build more security solutions rather than just recommending or auditing security for external teams.

This struck me as potentially an interesting trend. I’ve loosely observed the following trend in the banking industry related to security teams and technology (excludes other stuff like vendor management, disaster recovery, etc.):

90s = Security teams mostly handling granting/revoking access, password resets, operational security stuff.

late 90s/early 00s = Security teams adding more technical people to deliver specific security technology back to the IT teams (authentication, encryption, provisioning, some firewall/VPN, etc.) among other governance stuff like patching schedules, anti-virus, access control, web related security, etc.

Mid/late 00s = Security teams unable to add staff at the rate needed to function like a mini-IT shop within the larger IT organization, thus starting to “outsource” security technology back to IT and step up the audit, governance, compliance focus. They also start adding heavy technology assessment to their mix.

Early 10s to the present = Security teams pretty much 100% audit, governance, compliance, assessment focused. Little to no technology ownership/delivery maintained.

Thus, I described this trend to both individuals and went so far as to suggest that potentially, are we in banking approaching another pendulous swing back to security teams looking to re-in-source specific security related technologies that have been difficult to manage externally. They weren’t able to add a significant perspective since they were just absorbing technical delivery from being previously governance focused. Thus, I wonder if security technology delivery and ownership will oscillate between IT and security teams over time? I whipped up a crude graph to show, over time, the potential for such in-sourcing and out-sourcing of security ownership and delivery shift:

Thus, will bank security departments that have returned all security technology to IT find it challenging to audit and assess certain technology domains and thus re-absorb them over time? Will non-bank related firms that are just in-sourcing security technology delivery find they, like banks did, can’t scale and follow the recent banking IT trend and out-source? Is there ultimately a balance between governance and delivery of security technology? Clearly this isn’t Gartner level detailed analysis thus I would greatly appreciate others perspectives on my observation and trend suggestion.

Everyone participates in iteration planning meetings

Today is the third and final day of the Agile Boot Camp being hosted by ASPE SDLC Training. I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery. I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy. In order to appreciate this article, I suggest you read my thoughts and experiences from the first and second days.

First, the excellent Davisbase, LLC instructor finally revealed his contact information. I confirmed with him it was ok to share so here goes:

Rod Ashton

rod@davisbase.org

801-918-4092

I can’t stress enough that Rod’s real world experience in corporate IT project rescue and his on premise company Agile consulting experience were extremely valuable to making this course very pragmatic. Rod would physically step from the center of the room (Agile practice, process and theory) to his immediate left (real world) frequently to segue from theory to practical real world experience based guidance. This made the course triple in value for me. Lastly, at the end of the day today on the course feedback sheet, the best I could come up with on “needs improvement” was having white-boards for team exercises.

The third day is where everything really came together. Thus, without much lead in, here are my bullet point notes from the day:

• When asking why, consider 5 level of “why’s” to get to the bottom of the real need
• For developers that are stuck or struggling to break down a blob of work into tasks, lead them through their internal thought process of developing the blob with “what are you doing to do first? What are your going to do next? Next? Next? …”
• For product folks having trouble articulating what they really are asking for, try “if you could wave a magic wand, what would you want?” to break the potential log jam of real world constraints and competing priorities to get them to spill.
• Make all changes in small increments in order to “tweak” the output in order to achieve cadence.
• Always, rule of thumb = “simplicity”
• Considering the above two bullets, start with 2 week duration iterations in order to get feedback sooner and see results of incremental changes sooner.
• Agile plus continuous integration maybe the next hot thing in efficient and effective software development.
• To start to build team commitment, PM or Agile Coach or Scrum Master lock eyes with team members to get personal commitment on initial story execution until team auto-commits by default.
• No brainer, but how many organizations are realistic on capacity? 6 hours a day max on average of real employee productivity.
• Everyone, everyone, everyone involved in an iteration participates in iteration planning.

I captured some helpful tips on how to establish a new team’s initial velocity:

• Plan to do the hardest stuff first
  • Tolerance for mistakes from management, nay saying peers and others are higher initially and less so as time marches on.
• Time box one hour for estimating to encourage quick decisions and less conversational off topic drift.

All in all, it was a lot of material crammed into three days. Rod did a great job keeping the class moving and keeping attendees awake and engaged. Plus, as I said before, his real world experiences merged with the Agile principles and process really made the course outstanding.

Now, my challenge is bring all this knowledge into practical execution with multiple agile and non-agile development teams plus non-agile infrastructure and all the classic corporate IT structures.

Can you really multitask?

Today is the second of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.  In order to appreciate this article, I suggest you read my thoughts and experiences from the first day.

With the basics of the history and the initial ground rules out of the way, now the class can dig into the meat of Agile.  The instructor started the second day with an interesting exercise. We were asked to do three things, each time boxed to two minutes:

On a piece of 8.5 x 11 regular white paper, do the following (2 minutes each):

• Write as many numbers as you can, 1, 2, 3, 4+
• Write as many letters of the alphabet as you can.  When you reach Z, start again with A
• Write as many letters and numbers as you can: A1, B2, C3, D4+

At the end of each 2 minute writing exercise, he captured the top number of entries from the class.  What was interesting and the point of the exercise: no one did particularly well on the letters and numbers exercise.  Even the clever people that tried various techniques to write faster failed to write as many entries as either numbers or letters only.

The point = people can’t multi-task as effectively as they think they can.

Or as I’ve come to appreciate this topic:

Context switching has a price.  That price can be around a 20% loss of productivity as a whole when someone is assigned an additional concurrent task to complete.

Many, many articles support my statement above. One classic is Joel Splosky’s “Human Task Switches Considered Harmful”

Early in the day, someone asked the instructor to share his opinion on if a team commits 100% to start being Agile, how long should it take to go from starting with high frustration to running smooth with little to no frustration.  Mind you, this is just his experience seeing companies and teams take on Agile, but in his opinion:

New Agile Team, 100% dedicated resources = 12 weeks or approximately 6 iterations

New Agile Team working with a vendor = 24 weeks or approximately 12 iterations

New Agile Team + vendor + contractor(s) = 36 weeks or 18 iterations

In more Agile terms, the project team requires the durations above in order to have more of a constant/predictive velocity and established cadence.

It was striking to see how the external elements of vendors and contractors double and triple the time it takes for a team to achieve a predictive Agile rhythm.

As we learned about good story creation and planning poker and relative estimating, I jotted down some Agile success themes that struck me throughout the day:

• Product Roadmap creation forces collaboration amongst all stakeholders.
• Serious Agile success is achieved when the business starts asking how to use Agile for their business work to be as productive as IT.
• Stories are from the user perspective, who, what and why … if you can’t define the “who”, then stop all work/discussion on that story.
• Agile requires a culture that encourages everyone to ask questions of everything
• Stories can come from anyone on the team … developer has an interesting idea about a product feature?  Write up a story for the backlog.

One of the more challenging topics to get ones waterfall head around was the planning poker or story estimating.  I wasn’t alone, a number of technical folks were asking questions around how it is possible to say this work takes “8 units” without completing that phase with “ of hours/days/weeks”.  Most classic corporate IT budgeting and projects need estimates of actual X features completed by Y.  Agile works under more of a “line of credit” concept stating: given Y amount of time and Z resources, X features will most likely get done assuming some velocity with cadence achieved.  I’ve tried to capture this challenge in more detail in this previous post on “Agile versus Classic IT Budgeting”.  For many classic corporate IT shops, this is a huge cultural challenge to overcome.

I am looking forward to getting back together tomorrow for the final day of talking about how to slot in stories based on priority and work units against the roadmap as well as release planning.

Demo Early, Demo Often?

Today is the first of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.

The first day covers the history and an introduction to Agile.  It also covers the forming of Agile teams, creating the product vision, focusing on the customer and the product road map.  The instructor was a little slow to get going, but once he got past the high level introductions and the brief history of Agile, things started to move quicker and get more interesting.  The class is full of people from all industries and job roles.  There are people from manufacturing, health care, insurance, government, consulting and financial services.  There are developers, managers, business analysts and project managers.  The class is mostly people without much if any Agile experience, so the pace of the course is perfect for the majority of the attendees.  Given my personal research and light weight implementation of a hybrid of Agile principles in past professional lives, I could see the course moving through material and concepts much quicker.

The instructor had us split into three and four person teams to do some exercises that support the content of the course.  Each team is given some very loosely defined requirements such as make paper airplanes that can achieve a certain goal or organize a pile of colored paperclips.  Once the exercises are completed, the instructor reveals the Agile specific principles involved in the particular activity.  This teaching technique is a creative way to get introduced to the theory before actually being told that theory from a strictly academic sense.  In the examples of the paper airplanes, team members self-organized into airplane designers, developers and testers based on the ad hoc team members basic personal/professional strengths.  I was amazed my high school mentally distracting interest in creative paper airplane construction coupled with the CWRU Strosacker quest to make paper airplanes glide gently over the crowd to softly bump into the main screen to the gleeful cheers of the students in the audience that came in handy today.

After today’s session, in chatting with the instructor, I learned he is a 25+ year veteran of globetrotting in order to rescue projects that are in trouble for time and/or budget reasons for American Express and other multi-national firms.  His hands on real world corporate and consulting experience gave additional credibility to the course material.  Some of his helpful, but maybe not strictly textbook knowledge shared included:

• Demo early, demo often = don’t wait till the end of the Scrum sprint to demo the product increment.  Get feedback ASAP in order to handle possible course correction.
• Team best practices =  Open and Honest Feedback = Direct, Specific and Non-punishing
• Plans are useless, planning is indispensable.
• Documentation is required, but only to the lowest level necessary.  “Do what it takes to barely get by”

I am looking forward to getting back together tomorrow to talk about creating and maintaining a product backlog, prioritizing that backlog and estimating work plus release planning.