Midwest IT Survival

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.

Get consensus or get lollipopped**?

From solving competing priorities that are affecting your resources to when to ratchet up the risk management opportunities on a high profile project that is approaching a critical deadline, as a MidWest IT manager, you are constantly forced to make decisions.  IT Engineers are also constantly making decisions, but the impact has a slightly more narrow focus where as, an IT Manager’s decisions have a much wider, more macro focus.  Plenty of the IT Manager’s job stress is directly related to having to constantly make decisions that have a macro as opposed to micro impact within the organization.  This article touches on some considerations for IT Managers to judge when one is solely empowered to make a decision compared to when it is more appropriate to solicit feedback from peers and senior management prior to making a decision in an effort to reduce that stress.  Or more simply, as the article is titled, an attempt to help you reach out to your peers, staff and management to answer the question of how much decision latitude does an IT Manager have within their organization?

In the previous article, once you got past the mild disclaimer, the article dove into the first consideration of engaging your manager what will most likely be a series of discussions surrounding the autonomous decision making abilities extended to you and how much your manager is willing to support.  In this article, adding the considerations of engaging your peer managers and your direct reports in extending you decision latitude purview.

Consideration #2 = Peers, what decisions can and can’t you make?

Along the similar thought process of strategically asking your boss for decision latitude parameters, leverage you new job or role assignment to engage with peer managers for their feedback.  Consider the example decision latitude conversation starting questions below:

“Hey Bob, I’m new to Company X as the manager of the FlimFlam engineering team.  I heard you are the manager of the enterprise integration team.  At my last place, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a software component.  How does decision making for stuff like that happen here from your perspective?”

“Hey Sally, I think we met before.  You are in the customer service department as the shared services manager, right?  I used to be the support manager in the IT employee services department.  Due to the re-org, I am now the manager of the FlimFlam engineering team in the customer delivery department.  Where I came from, I had to get five signatures on a form and a stamp of approval from a review committee in order to get a decision on the name of a server.  How does decision making for stuff like that happen here from your perspective?”

By and large, people enjoy sharing their opinions.  Also, people generally respect and appreciate a well articulated question that appeals to their superior knowledge in their area of expertise.  Thus, another by product is a peer manager you may need to work with heavily in your new role will have a positive initial impression of you.  Additionally, you gain valuable insight into their personality, professional capability and leadership style that could be handy when the future need arises to interact with this individual in a potentially challenging situation.

Can they form a well thought out, intelligent response to your question?  Yes, they maybe worth spending more time with gaining knowledge about your new surroundings.  No, they maybe a low priority time investment going forward.  Do they immediately reveal they have an ego that indicates their cube might not be big enough for both you and their ego to fit comfortably?  Yes, and then file this away for a future encounter where an ego stroking communication style would benefit the next exchange.  Do they appear overwhelmed and oozing stress from every pore in their being?  Yes, then whatever feedback they provide might not be particularly valuable since they could very well be stressed due to ineffective decision making.

The topic of decision latitude is a great excuse to get some valuable interaction and intelligence from your peer managers.  One note, the above question and answer examples are just some thoughts to get your head thinking and not a direct mapping to a finite decision latitude specific determination.  Many other factors could be motivating an individual to respond to your initial queries a certain way such as an out side of work challenging situation.  Thus, the above suggestions are a means to get you thinking about starting dialogs with your peer managers to start to build a decision latitude framework that is ever evolving.

Consideration #3 = Ask your direct reports how decisions were made previously?

In the same thematic vein as interacting with your peer mangers, asking your new direct reports on how decisions were made prior to your arrival is another wealth of decision latitude information with a similar by product: ability to start building trust with team.

A fault of some IT engineers that get promoted into management or sometimes managers in general get a sense that because they are managers, they must make decisions because they are managers.  Be it ego or the power trip that comes with having influence over others, some managers tend to assume they know everything and thus must make all decisions without consulting anyone let alone their direct reports.  Nothing reduces engineering employee engagement and morale more than an engineering team that has a manager that is off making all kinds of crazy decisions without consulting his or her staff.  Time after time I’ve seen these individuals consistently get reorganized from team to team until they eventually get lolipopped** on the organization chart.  Does anyone want to take a guess on who disappears in the next round of staff reductions?

Using this situation to your advantage, a great way to start to establish a rap pour with your new team is to solicit their feedback on how their previous management made critical decisions.  They probably have a laundry list of past examples of good and bad scenarios.  What is the old adage?  Those that don’t learn from the past are doomed to repeat it from the Spanish philosopher George Santayana.  Your new team probably has some great stories where their previous management went off and made a crazy decision to do something and the corporate drama that ensued.  Take this opportunity to allow them to share the details of decisions gone haywire.  Plus, listen to how each contributes to the discussion.  Who is talking the most?  Who has the most passion in their description of past events?  Who zones out during the discussion and has nothing useful to contribute?  The conversation will give you clues to how your new position fits into the organization’s decision making process.  Additionally, you will be able to gather valuable insight into your new team and what makes up and novitiates each individual.

Wrap up

Finding yourself in a new leadership position within a different department within your current company or starting a brand new job, how an IT manager participates in the decision making process can easily map to a how stressful the job turns out to be.  Running around feeling compelled to make quick, off the cuff decisions in an organization that possesses a culture of methodically researched decisions is one way find your job stress going up.  On the contrary, a culture where an engineering team doesn’t use the restroom without consulting with management is going to take a different approach to go from day one decision making to day X where you ultimately desire the decision latitude to exist within your sphere of influence.  Using the newness of your role presents a great opportunity to consult with your manager, peer managers and you new team members to get some decision making parameters.  Additionally, you’ll have the side benefits of starting a valuable dialog with your new manager around how they expect your role to be successful.  You will also have the ability to get a feel for how your role was or is expected to function within your department’s peer management pool.  Finally, by tapping the past experiences around good and bad decisions that impacted your new direct reports, you will gain valuable insight into what worked and what didn’t work in the past.  You will also begin to establish a rap pour with your new as a manager willing to listen and understand rather than command and control out of the gate.  This process of understanding the decisions latitude at your prevue is on going.  You can expect the minute you get a sense of comfort that you have a good grasp of when you can just decide on the spot rather than form a committee to launch a research team, there will be a re-organization or an acquisition or some other corporate event that will throw the balance out of whack.  Keep expecting the variability to be the normal state and try a more scientific rather than trial and error approach to having a good sense of your decision latitude.

** “Lollipopped” slang for a senior position on an organizational chart that doesn’t have any direct reports when peers at the same level have staff and potentially additional management layers below them.

Do I make the call solo or get consensus first?

From solving competing priorities that are affecting your resources to when to ratchet up the risk management opportunities on a high profile project that is approaching a critical deadline, as a MidWest IT manager, you are constantly forced to make decisions.  IT Engineers are also constantly making decisions, but the impact has a slightly more narrow focus where as, an IT Manager’s decisions have a much wider, more macro focus.  Plenty of the IT Manager’s job stress is directly related to having to constantly make decisions that have a macro as opposed to micro impact within the organization.  This article touches on some considerations for IT Managers to judge when one is solely empowered to make a decision compared to when it is more appropriate to solicit feedback from peers and senior management prior to making a decision in an effort to reduce that stress.  Or more simply, as the article is titled, an attempt to help you reach out to your peers, staff and management to answer the question of how much decision latitude does an IT Manager have within their organization?

[Mild disclaimer ahead]

Now I am not referring to straight forward decisions such as how often to schedule team meetings or how long before email responses would be considered tardy.  I’m referring to decisions that have a lasting or strategic impact.  Examples such as is it the right time to switch resellers or approval to kick off an expansive systems upgrade project or whether your team should provide an additional service that the organization is requesting that has new hardware, additional licensing and staff increase associated costs.  These are stress inducing examples.  Making say, a service extension decision autonomously, could land you in hot water when your boss finds out that, to be successful, you need more money and staff than the budget allows, yet the rest of the organization is moving forward assuming you are providing the new service.  Ever sit in an IT managers meeting with a cross department attendee list to sort out ownership of key services that need to come together to meet a new, high profile business need and watch a manager proverbially step right in front of a speeding bus by agreeing to provide a solution that everyone around the table knows they should have consulted their management prior to agreeing?  This sounds like the start of a series of high stress post meeting discussions.

Lastly, this article isn’t meant to be a step by step guide to stress reduction based on an all encompassing decision making strategy.  This article is more of series of considerations and possible approaches that might suggest a more structured approach to decision making rather than pure trial and error.

[End of mild disclaimer]

In my Internet wanderings, I came across this definition of decision latitude and its link to work stress:

“…the ability to make work-related decisions. When employees can make decisions related to the way they work, they are able to devise coping strategies than can mitigate the effects of stress” (Halpern, D.F., 159). *

Applying this perspective that how a MidWest IT Manager approaches the decision making process directly correlates to the amount of job stress experienced, one could simply extrapolate:

• Effective decision making, less stress
• Ineffective decision making, more stress

Note: I don’t think anyone could make the claim that effective decision making can eliminate all stress.  Rather, effective decision making can only reduce stress given some level of stress is involved in all decision making and as a manger; you are constantly put in a position to make decisions.  Ineffective decisions lead to an increase in problems or issues that force one to have to make even more decisions, thus repeating the cycle and in the process, bumping up the stress level each time.  Thus, if you find your job to be exceedingly stressful, have you stepped back and considered how effectively you are making decisions?

Consideration #1 = Boss, what can and can’t I decide?

The very first consideration is, for your role within your organization, what are you empowered to decide and what requires three committee reviews and seventeen signatures on a company form in order to decide?  Every company culture is different.  Plus, the larger the organization, the more cultural elements of the organization trickle down from division to department to group to team such that a role in one department might have a radically different tolerance for autonomous decision making compared to the same role in another department within the same company.  To make things even more challenging, with every reorganization or incremental leadership change at some higher level within the organization starts an eventual shift in the autonomous versus group decision making abilities.

So, how does one sort all this out within your organization?  Well, if anyone has a silver bullet answer for this one, I would appreciate hearing it.  In my experience, this is an ever evolving process of pro-actively seeking feedback coupled with reflection on the results of decisions made.  The most immediate source of proactive feedback is your direct manager.  If you are new to an organization or you find yourself suddenly reporting to a new manager, you may want to consider putting a high priority on this following example exchange within your first, formal one-on-one discussion:

You to your New Manager: “One topic I would like to cover is how you see this role empowered to make decisions within the purview of the team and the services it provides to the organization versus when I need your or others involvement.  As an example, in my prior role/organization/management relationship/etc., given a situation such as <insert example of recent past where you were completely empowered to make a decision without any additional peripheral involvement>, I was able to make decision X without having to involve anyone else and I knew I would have the support of my management.  In another example, < insert example of recent past where you had to involve your manager, peer managers, senior management, etc. prior to getting a decision made> I needed to directly involve my manager, peer managers and senior management in order to achieve a consensus on a decision.  Can you share your expectations on how much decision latitude you foresee my role having that you would support?  Follow up question, if a needed decision doesn’t fall within the parameters you see for this role, how best should I request your involvement in the decision making process?”

A couple nuances on this example exchange:

• Use of examples

If you asked directly what decisions you can and can’t make, you are likely to get an unhelpful response such as “I would expect you to make the decisions you feel necessary to get the job done” and then leaving your new boss with the impression you are somewhat weak since you had to ask such an open ended question.  By sighting examples on both ends of the decision spectrum and the circumstances that lead up to your autonomous or consensus based decision, you provide your new boss with context as to why you are asking the question.  The context created by the examples allows your new manager to consider your question within the realm of his or her leadership style.  Plus, you will gain valuable insight into your new manager’s priorities and approach to their role.  If your new manager suggests they need to be involved in every decision, you will get a clue they my have micromanagement tendencies or need to reach a level of trust before they are willing to allow you to function somewhat autonomously.  If your new manager suggests they don’t need to be involved at all on anything, you maybe getting clues you are reporting to an “arm chair” or “Monday morning” quarterback manager who will need to be drug into decisions that they would otherwise enjoy you make and then criticize later.

• “Decisions you would support” caveat

The value of adding this to the end of your big question is to get what you really need from your new manager.  Similar to clues you get from the context setting of your examples, what you are really looking for is your new manager to support your decisions not just allow you to make them.  Having this phrase at the end of your question emphasizes this critical component of your question.  You may want to consider the use body language and voice inflection to politely draw attention to these last few words so you ensure you have your managers focus on the words lest they are already formulating an answer based on your lead in statement to the question and examples.

• Follow up question on how best to engage your new boss

Equally critical is establishing some parameters around the best way to engage your new boss when they need to participate in making a decision.  Again, you gain value insight into your new boss’s leadership style based on the answer.  Equally important, as opposed to trial and error, you now have parameters by which you can engage your boss in decision making.  Thus, as a situation pops up that requires you to make a decision, if it in any way meets this parameter, your stress level doesn’t have to rise significantly.  Instead of stressing, start capturing the information needed and approach your boss as they outlined.  Fight the immediate reaction of making a decision on the spot.

• Potentially the greatest value = the exchange itself

Just by having this exchange, you begin the process of establishing a level of trust with your new manager.  They should begin to perceive you as one that values the reporting relationship as well as management pressures that exist at both your and your boss’s level.  They should observe that you value their reputation and role within the organization through establishing these operating parameters.  Just like you don’t appreciate having to navigate around a crazy decision made by one of your team members that puts you and your team in a bad place, your new boss does not look forward to having to respond to crazy decisions you make.

Finally, by having this exchange very early in the new reporting structure, you lay the ground work for on going dialog on the subject of management supported decision making until you reach that level of trust where the parameters and boundaries are firmly established.  Sure, you could learn these parameters and boundaries through trial and error, but why endure the stress and proverbial bruises when asking a strategic set of questions that could avoid the entire steaming pile of cow dung associated with making a call you shouldn’t have made on your own plus have the side benefit of building valuable trust.

In the second part to this topic, look for considerations around how to involve peer managers and direct reports in extending you decision latitude purview.

* Halpern, D.F. (2005). How time-flexible work policies can reduce stress, improve health, and save money. Stress and Health (21), 157-168.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as an IT manager that has a role to play on an IT project.

In the previous article, I recommended two situations in which you need to strategically determine when you and your team need to not be connected to a particular project.  In certain situations, being connected to a particular project will actually cause you and your team more harm than good.  Below I’ll outline a third situation where the more distance you can create between yourself and your team from this type of project the better.

Situation Three: production support-ish project involving the terms “ruggedization” or “hardening”

These projects usually form after a major system outage where the outage was severe with critical systems being down for a long enough period of time that higher levels in the organization were distracted from their usual duties.  These distractions involve participating in discussions as to what they might have to sign off on as far as alternative service delivery options if the outage were to extend further.  Since higher levels in the organization were forced to get involved, they want to see what is going to transpire in the near future to ensure this involvement isn’t required again.

The scopes of these projects sometimes are legitimate identifications of technical gaps in a system that indeed need shoring up.  But in my experience, they are more born from a bunch of managers needing to craft a story of how strategic investments were not made in the care and feeding of a given technology service and this “ruggedization” project will ensure this type of an outage never occurs again.  The crafting usually is done in haste to combat the high levels of the organization asking the obvious questions: “why did this happen?” and “what are we doing to make sure it doesn’t happen again?”  Thus, the crafting is more political than strategic at this point and once the crisis dies down and a new crisis is brewing, the whole effort becomes quickly forgotten.  What usually contributes to the proverbial death of the project is when someone compiles the costs associated with ruggedizing against the lack of a budget pre-forecasted to do such work compared to all the work in the budget that still needs to get done by essentially the same people.  Unless the ruggedization is so unbelievably critical IE., jobs are literally on the line, someone in the organization won’t be willing to sacrifice their budget of work that could get them a raise and/or promotion (part of their goals and objectives) for some investment in some weak technology that probably won’t break again within the current organization structure and before the next reorg.

This analysis may come across as a very negative slant.  I would argue that if you can dig into peoples’ struggles with balancing the new work against the unplanned “ruggedization” work, you’ll see a trend of the “A+B” players working on the new work and the “C” players getting assigned the “ruggedization” work which supports my slant.

In these situations, knowing that the project was formulated under these conditions is potentially the most critical piece of data to establish and retain.  Getting ones hopes up that this project is going to actually complete and deliver the outlined system improvements is prone to disappointment at best.  But having the knowledge that this projected existed at some point in the past can come in very handy in these kinds of situations:

Get ready for a fight

Support Manager: <somewhat irritated and on the verge of becoming irate>  “Why is the FlimFlam replication widget crashing again?!  I thought engineering was fixing that so it would never happen again?!”

Engineering Boss: <remaining calm, impersonal and answering the questions with more questions> “Wasn’t the FlimFlam Ruggedization project supposed to take care of that problem last year?  Did that project ever get completed?”

Support Manager: <Somewhat stuck> “Um, I don’t think so.”

Engineering Boss: <still calm> “I seem to remember it stalling when the cost of the redundant hardware was calculated in order to make the widget highly available.  Who needs to be engaged to kick that project back off again?”

An approach similar to the above removes the building emotion.  It also points the imposing finger of blame back to the nebulous ruggedization project that never completed rather than someone in the room.  Plus, alluding to why the project stalled in the first place implies the same exercise (in this example, high cost) will need to be re-evaluated with more than likely the same output: project stall.  Don’t be alarmed if the same cost collection process kicks off because it shows management is doing something in reaction to the severity of the outage … just know it will probably end in the same state as prior … thus you can relax and not be overly concerned as history repeats itself.

In summary, these articles provide some food for thought when it comes to how you, as an IT manager, want to structure you and your team’s involvement in IT projects of a given theme.

How to Survive Your Role on a Project as a Manager, Part 3

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a project.  Now if you have spent any time in IT you have probably had a role on one of these things called a project.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that everyone is accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as a IT manager that has a role to play on an IT project.

In the previous article, I recommended two situation in which you need to strategically determine when you and your team need to not be connected to a particular project.  In certain situations, being connected to a particular project will actually cause you and your team more harm than good.  Below I’ll outline a third situation where the more distance you can create between yourself and your team from this king of  project the better.

Situation Three: production support-ish project involving the terms “ruggedization” or “re-write”

These projects usually form after a major system outage where the outage was severe in that critical systems were down for a long enough period of time that higher levels in the organization were distracted from their usual duties in order to participate in some discussions as to what they might have to sign off on as far as alternative service delivery options if the outage were to extend further.  Some are legitimate identifications of technical gaps in a system that indeed need shoring up.  But in my experience, they are more born from a bunch of managers needing to craft a story of how strategic investments were not made in the care and feeding of a given technology service and this “ruggedization” project will ensure this type of an outage never occurs again.  The crafting usually is done in haste to combat the high levels of the organization asking the obvious questions: “why did this happen?” and “what are we doing to make sure it doesn’t happen again?”  Thus, the crafting is more political that strategic and once the crisis dies down and a new crisis is brewing, the whole effort becomes quickly forgotten.  What usually contributes to the proverbial death of the project is when someone compiles the costs associated with ruggedizing against the lack of a budget pre-forcasted to do such work against all the work in the budget that still needs to get done.  Unless the ruggedization is so unbelievably critical IE., jobs are literally on the line, someone in the organization won’t be willing to sacrifice their budget of work that could get them a raise and/or promotion for some investment in some weak technology that probably won’t break again within the current organization structure and the next reorg.

In these situations, knowing that the project was formulated is potentially the most critical piece of data to retain.  Getting ones hopes up that this project is going to actually complete and deliver the outlined system improvements is prone to disappointment at best.  But having the knowledge that this projected existed at some point in the past can come in very handy in these kinds of situations:

Support Manager: <somewhat irritated and on the verge of becoming irate>  “Why is the FlimFlam replication widget crashing again?!  I thought engineering was fixing that so it would never happen again?!”

Boss: <remaining calm, impersonal and answering the questions with more questions> “Wasn’t the FlimFlam Ruggedization project supposed to take care of that problem last year?  Did that project ever get completed?”

Support Manager: <Somewhat stuck> “Um, I don’t think so.”

Boss: <still calm> “I seem to remember it stalling when the cost of the redudant hardware was calculated to make the widget highly available.  Who needs to be engaged to kick that project back off again?”

An approach similar to the above removes the building emotion.  It also points the imposing finger of blame back to the nebulous ruggedization project that never completed.  Plus, alluding to why the project stalled in the first place implies the same exercise (in this example, high cost) will need to be re-evaluated with more than likely the same output: project stall.

In summary, these articles provide some food for thought when it comes to how you, as an IT manager, want to structure you and your team’s involvement in IT projects of a given theme.

I think it is safe to say that anytime any company wants to get something new accomplished they “kick off” this thing called a “project”.  Now if you have spent any time in IT you have probably had a role on one of these so called projects.  You know when you are on a good project:

• Everyone knows what the end goal is.
• Everyone knows each others roles.
• Everyone has a sense that all participants are accountable for their tasks.
• Things are getting done.
• Everyone feels a sense of progress.
• Everyone feels a sense of team.

You also know when you are on a bad project:

• Everyone is seemingly bumping into each other.
• No one can really articulate the goal of the project
• No one knows what the end state is supposed to look like.
• Time is going by with meetings and minutes and status reports but no real tangible work is getting done.

This series of articles will cover different aspects on how to survive as a IT manager that has a role to play on an IT project.  The first article in the series is here.

First recommendation: delegation of project attendance duties.

First and foremost, you must admit that you can’t be everywhere at all times.  You can’t be in every meeting.  You can’t ask every question and get the answer first hand.  Thus, you have to develop a system for determining if you need to know about a particular project or not.  And if you do, do you need the information first hand or would a staff member be able to gather the information for you.  One easy way to determine if direct attendance is needed is if peer managers are planning to attend.  Although this isn’t always easy to determine, just because the invite list has a laundry list of names of peer managers doesn’t mean they all will indeed be attending directly.  This is where having a sly way to contact the meeting organizer and schmooze yourself a list of who has accepted, denied and not replied is helpful.  If all this recon fails, error on the side of caution and attend.  A brief note, if your company has multiple locations, dialing to a meeting via conference call rather than attending in person can be an efficient way to get the information you are looking for without sacrificing valuable hours of the day.  A word of warning, if all your peer managers are in the room and you are on the phone, you will potentially miss valuable non-verbal and post meeting chatter.  Thus, choose your attendance vehicle carefully.

If the focus of the meeting is not geared towards managers and your peer managers aren’t attending, then seriously consider delegating attendance to a staff member.  If you team is full of heads down engineers who would rather be hands on with technology rather than sitting in a meeting hear about some else talk about what some project is going to do with technology, then try and spread the meeting attendance burden around so no one gets dumped on with meetings.  I’ve found that if you are overtly clear on exactly what you need this staff member to absorb, things usually go well:

Boss: “Bob, I have a conflict and can’t make the FlimFlam Upgrade kickoff meeting.  I need you to attend and gather some info.  Specifically, you should announce yourself as part of our team and explain you are in attendance to understand the scope of the project but are not assigned as a resource.  For any resource assignment, have them give me a call.  What I think the team needs to know from this meeting is if the FlimFlam software is going to need a widget to interface with the accounting service.  Thus, if by the end of the meeting no one has mentioned the need for a widget, please ask directly if the project scope includes the requirement to build a FlimFlam to Accounting widget.  After the meeting, please let me know how the meeting went and if a widget is needed.”

What do I need to know?

Obviously, as you are more in the routine of having staff members attend meetings, the level of formality to the request to your staff can relax.  Just a word of caution, in the process of relaxing, make sure you still put energy into making sure the role the staff member plays and the questions you need answered are made clear.  It is easy to relax in these frequent requests to staff and if you start assuming the staff member knows what you need from them without explicitly confirming with them, you run the risk of have lost a premium opportunity to get info when you need it.

Next recommendation for the next part in the series: strategically determine when you and your team need to not be connected to a particular project.