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?

Related posts:

1. Senior Management Communication for the Technically Proficient Part 1
2. Senior Management Communication for the Technically Proficient Part 2

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.

No related posts.

Project sponsor turnover can be handled smoothly

Hallway conversations and whispers in meetings have the grapevine quickly communicating the departure of a highly visible person in the corporation. “Did you hear Bob gave his two week notice?” “Yah, any idea where he is going?” “No, I don’t think he shared that.” “Who is going to lead the big FlimFlam upgrade project now?” “Don’t know that either. It hasn’t been announced. Bob has been it for as long as anyone can remember.” “This could get very messy.”

I was reflecting on my participation in a large, multi-track, multi-phase, multi-year project some time ago. So, safe to say, this was a big project involving substantial change across a variety of technology groups, products and business units. About a third of the way through the project, the day to day business sponsor left the organization for an outside opportunity. Since the project was well under way, being a third completed, a new sponsor was needed to step in quickly to keep providing direction to all the concurrent work streams.

Executive Leadership Steps In

The executive sponsor immediately started attending the regular program level status meetings. This provided much needed leadership. Thus, two big thumbs up for her participation. Instead of everyone looking around the table at each other wondering who was in charge, there was continuity in project leadership.

New Sponsor Arrives

The executive sponsor didn’t waste much time sourcing a new business sponsor for the project. With only a few weeks of drift, a new day to day sponsor was at the table. The executive sponsor gave a brief introduction and the new sponsor took charge. Following the introduction, it was clear to everyone that the new sponsor wasted no time getting up to speed even though he had no prior knowledge of the project nor subject matter expertise in the goals and objects of the project itself. The new sponsor already had had meetings with key stakeholders individually.

New Sponsor Sets the Tone

The new sponsor also gave brief summary of the current state of the project, the major open issues and summarized the strategic next steps. In summarizing the next steps, the new sponsor established an immediate credibility as the prior sponsor seemed to be struggling a bit with how to prioritize the cross-functional team’s focus for the in-flight work streams. All in all, the new sponsor, in the first formal meeting, established a strong confidence that had everyone leaving that meeting with a positive sense of enthusiasm that we were all in good hands for the remaining work ahead. The new sponsor clearly set the tone for project success.

So what made this potentially negative situation result in a re-energizer to the project team?

• Executive leadership presence immediately upon word the current sponsor was leaving the organization.
• Executive leadership remaining visible and actively engaged through naming the new sponsor.
• The new sponsor’s strong initial engagement and clear understanding of:
  • Project’s current state
  • Clarity surrounding open issues
  • Ability to articulate next steps.

Has anyone else experienced a positive project sponsor change? What contributed to the success of the leadership switch?

Related posts:

1. Aha Moment: Technical People need Project Managers
2. How to Survive Your Role on a Project as an Engineer, Part 4

Get too tactical and get set on fire

I read Neil’s “How to do Nothing” blog article on the topic of effective management back when I first discovered his blog earlier this year (2010).  I was struck by the pure simplicity of his eight attributes of effective team management at the time.  Neil was gracious enough to comment on a recent article I published on agile project management reducing application over architecture.  I went back and re-read his article and realized it is even more impactful on successful team management than I originally thought.  I thought I would take a few paragraphs to further extend the concepts Neil outlined in this article.

Anticipate rather than react

Neil suggests having your hair on proverbial fire frequently by getting hands-on in addressing issues isn’t the most affective approach.  I agree with him that in these hair-on-fire situations, it can be exhilarating to roll-up your sleeves and jump in and be the hero that saves the project or restores production service, etc.  Once a sense of calm returns after the hero has saved the day, the hero starts itching for the next crisis to be the savior and the behavior gets repeated.  The hero may get initial fame and glory, but it is short lived.  In my experience in multiple MidWestern companies, the hero ultimately gets revealed for his/her display of reactionary management.  Senior management begins to grow tired of the peaks and valleys of crisis, pending doom, disaster avoided, pause and repeat for the next crisis.  I’ve also seen the hero scratch their heads when the next re-organization comes along and the hero finds him/herself as a technical lead over a team with a new management layer above them.

Maintain relationships outside the team

I definitely agree with Neil here.  I would even add the larger the organization, the more this is essential.  As your team provides a service to a larger project or effort, the number of ways other teams can throw a wrench in the works is almost immeasurable.  In addition, the message that gets filtered to your team and then to you may be completely disconnected from the real blockage.  Being able to pick up the phone and call a peer manager, with whom you have established a rapport, and get right to the real issue is invaluable.  Once the real issue is known, you can offer guidance to your team on how to navigate to a successful path forward.  Without this knowledge gleaned from a peer manager, you can easily get caught up in the panic the blockage creates and risk being set on fire in the process.

Big visible task boards

In a word: absolutely!  By all means, assuming everyone knows what to do is a recipe for disaster.  A disaster in a sense that tasks won’t get executed according to plan and you will be dragged back into strategizing on how to go forward while accounting for the missteps of the past.  As Neil says, use a whiteboard or in my case, use some electronic task tracking system that isn’t overly cumbersome yet makes it unbelievably clear who is working on what, doing what and when.  Have you ever considered using your bug or defect tracking system as a light weight task tracking mechanism?

Team collaboration

I’ve written on this topic in the past relative to the leveraging of self-organizing, strong teams with a focus on intense collaboration.  If you make yourself a keeper of all knowledge, you will constantly be engaged to assist with tactical decision-ing and thus at risk of again, being set on fire.  If you drive team members asking you questions back to fellow team members, they will start going to fellow team members directly.  Clearly, once this occurs, you will need to be contingent of when you will need to specifically instruct your team to collaborate with you when you are engaged in some issue that you aren’t at a point of delegating just yet.

Small incremental changes

If you are considering pitching or implementing a significant change that you have dreamed up that will get everyone working better, more efficient and at the same time cure cancer, you might want to put on the brakes.  People accept change in a variety of ways.  The more aggressive the change from the current norm the more likely you will have to invest additional time in addressing how each impacted individual reacts to the change.  If you stretch your change implementation out over time so it seems like you are providing “just in time” solutions to the ultimate problem, you will most likely achieve a more successful end result all around.  Plus, with each incremental small change, you can more easily course correct or tweak your next change to be even more effective and hopefully, even less visible.

Inspect and adapt

Getting the team to contribute ideas and suggest process improvements takes the decision-ing pressure off of you and empowers the people doing the work and most impacted by the process to suggest the most effective improvements.  Plus, if the team is on board with an improvement, they are more than likely to make the implementation successful, because it is their improvement.  On the flip side, how motivated are you if you have the ultimate “my boss told me to do it, thus if it doesn’t work, not mu problem” excuse at the ready when the slightest problem is encountered?  What motivation does anyone have in that situation to try and make it work?

Hire great people

These almost goes without saying … hire great people and then just get out of their way so they can do good work.

Commit to personal development

If don’t have the flexibility to move poor performers out and attract in top performers, and let’s face it, MidWestern companies don’t always have the most flexible staffing models nor the local talent pool to quickly make team changes happen.  Bringing up the level of your current team is more than likely your best option.  Take advantage of any tuition or training bugets available to strongly encourage folks to get away from their desks and get exposed to some additional improvement perspectives.  Consider incremental “stretch” assignments to use as opportunitties to challenge those that have a weakness in a certain skill set.  Catch up with them “offline” and chat with them about what problems or challenges they are facing and offer some tips to help them get over those hurrdles.

Summary

In summary, the concept that a strong manager is precieved to be “doing nothing” is a compelling goal for any team manager to attain.  By essentially making it a top priority for you to empower your team to function as autonomously as possible, it allows you to focus on inter-company relationship building and other functions only you can do.  It also allows you to identifying process and skill set weaknesses without being tactically involved in the work to consider small, incremental improvements and then absorb the result.

No related posts.

Impromptu Team Meeting in the Conference Room

Is venting starting to turn everyone too negative?

Bob the Engineer <very agitated>: “Geez, that project ‘critical path’ regroup meeting was a huge pain!”

Sally the Engineer <visibly frustrated>: “Yah, if only the project managers were listening to us all last month when we were telling them their schedule was ridiculous!  There was no way back then the work was going to get accomplished when their fancy project plans said it would and we told them!”

Joe the Engineer <rolling his eyes>: “How many times are we going to have to attend these silly ‘we knew were going off track a month ago but we did nothing so now we need to have a meeting to chat about why we are suddenly off course  …’”

Bob the Engineer <speaking over Jo>: “We are going to have these meetings as long as the PMs keep ignoring our work estimates.”

Sally the Engineer: “Yah, when will they ever learn?”

Groupthink is any easy trap to fall into.  Yet, in my opinion, fostering a team climate for which there is an opportunity for such venting provides benefit to the entire team.  With a team sense of shared success and shared pain, the team climate evolves to allow team members to be open with their teammates and their manager on problems, issues, challenges and successes with more candor.  The openness breeds more open communication and cooperation plus ultimately leads to high quality output in less time with problems surfacing and resolving earlier in the work processes before they become disasters.  Yet, left unchecked, this venting can take the team as a whole deeper into the short term comfort of the shared pain and away from the need to look at opportunities to avoid the situation that causes the pain in the first place.

It is time for someone to be a leader and jump in and pull the team back from the precipice of groupthink.

Boss/Engineer: “OK, OK, ok … we all know the PMs get themselves into this situation more often than seems warranted.  How about we brainstorm on some creative ways we can do things differently going forward so we don’t have to sit in these useless regroup meetings?”

As an Engineer, this is a great opportunity to demonstrate leadership skills in front of your boss with real credibility.  As a Manager, if no one on your team is stepping up and the level of negativity is rising, you may have to step in with similar comments to redirect your team to focus on positives before the negatives further spiral the team down a bad path.

Anyone have any perspectives to share on groupthink?  Anyone have a technique or example where groupthink was avoided or not avoided resulting in a bad situation getting worse?

1. Janis, Irving L. Victims of Groupthink. Boston. Houghton Mifflin Company, 1972, page 9.

No related posts.