Midwest IT Survival

The challenge to integrate Architecture and Agile

Recently on Simon Brown’s blog “Coding the Architecture”, Simon posed are interesting challenge of which this article provides my response. I enjoy Simon’s blog for he presents very well thought out articles on the challenging overlap between Agile software development and the value of architectural principles in providing software solutions. As those that frequent my blog have seen, I’ve written about the challenges of integrating pure Agile development methodologies into non-Agile organizations such as legal services, manufacturing as well as financial services. I’ve approached the topic of work estimation here which is a frequent challenge in non-agile organizations that make project and resource prioritization decisions based loosely on the estimated work effort. I’ve tried to successfully blend Agile story and blacklog project management with the preponderance for waterfall-esk program management here. Based on the comments to that article I didn’t succeed in my goal. I’ve even broached the Agile versus architecture question before here but the focus was on the Agile reducing over architect-ed solutions rather than taking Agile versus architecture head on. I’ve even discussed budget challenges before.

Simon’s challenge: Given a four month window to deliver a new software project in an Agile shop, how would one go about doing so given some interesting constraints? The below graphic is from his blog post that captures the unique constraints for this challenge:

Based on my multiple years in the financial services industry working for more than one bank, I feel the need to outline some immediate assumptions that pop into my mind that are tainted by my direct banking experience:

1. Design Firms – Simon’s challenge involves the bank undergoing a new branding effort. In my experience, a bank’s internal marketing department partners heavily with an outside marketing firm for larger banding initiatives. Additionally, new branding efforts usually involve getting that new brand message out through a variety of channels.
2. Middle-ware/SOA capability – Given the overall growing maturity in the service oriented architecture space and the relative IT budgets of most financial institutions, I am going to assume there is some middle-ware, messaging and/or enterprise service bus-like capability to leverage.
3. Content Management System/CMS – Given the explanation of the current state online banking system, I am going to assume the bank does not currently have a mature content management platform which can be extended to provide online banking functionality.
4. Backoffice – Also, I am assuming that the bank currently has a backoffice transaction system that currently performs the bank’s core bank product transaction needs. For the sake of this exercise, a “legacy” mainframe set of applications are in place that run the core bank transactional services that has some capability to expose those transactions to the middle-ware/SOA platform.
5. Build versus Buy – A classic challenge for banks has been the decision to put the focus on building in-house capabilities versus buying mature vendor solutions and integrating those into the technology portfolio. Depending on the financial health of the bank itself as well as the predilection of the CIO, the build versus buy pendulum can swing to either extreme. Add the frequent turn over of senior IT leadership and this can be a real challenge for enterprise architectural patterns. For the sake of this exercise, the assumption is that the bank is willing to invest in the middle-ware transactional capabilities in-house as well as the supporting online banking application user experience but prefers to purchase a new content management solution to host the UI.
6. Big Bang versus Functional Sequence based rollout – I am also assuming product management is risk adverse and open to sequencing in the new functionality rather than demanding a big bang approach. More on the sequencing later in this post.

Given the architecturally significant changes requested in 4 months, specifically the read-only to real-time transactions and the complete hosting re-platform need, I would convince management that it would be infeasible to deliver everything in 4 months. Yes, the project management side of my brain says don’t over commit given the technical complexity involved and the linkage to a significant customer impacting change.

Thus convinced, I would then break the effort into multiple parallel technical efforts:

Re-brand current site = I would spin up an Agile team including the online banking product management/manager to focus on re-branding the current site between now and the 4 month end date. The team’s priority would be:

1. Integrate the new branding into the current site working heavily with the outside design firm
2. Make changes, assuming no conflict with #1 above, to improve W3C compliance

Create re-useable transaction services = I would spin up another Agile team that has the mission of exposing the backoffice transactional services as “enterprise” consumable web services through the middle-ware platform. The stories would mix both the technical needs such as “Develop a way for the middle-ware components to authenticate to the mainframe components” as well as business capabilities “have the ability to transfer unlimited funds, subject to current available account balances, from one customer owned account to another account owned by the same customer”. The prioritization of the stories would be as follows:

1. Architecturally needed stories such as component to component authentication, high availability, etc. Basically, everything needed to support #2 below.
2. Transactions needed in the new online banking product based on the roll-out schedule.

One of the challenges for this team is the likelihood that the mainframe platform participants are not familiar with Agile practices. Thus, extra coaching is probably a must for this team.

Purchase Content Management Product = I would task the architecture group to work with procurement to select a vendor’s content management product that will become the framework for the new transactional customer user experience. The classic steps would be undertaken: RFI/RFP, product evaluation, proof of concept, vendor pricing negotiations and ultimately product selection. This needs to be completed in enough time for the next team to be able to deliver some functionality in the new CMS product.

New UI Development = Finally, I would spin up another Agile team to map out and build the new transactional UI. Their first challenge would be to reverse engineer the customer authentication system to determine how the system authenticates users and then links them to their accounts and products with the bank. They would need to work closely with the re-branding Agile team to determine the most seamless way to add navigation to the current site to link over to the new site for the real-time transactional capabilities. Additionally, this team would also have to work with the middle-ware team in order to understand the re-usable services being created and how to consume them. Lastly, this team would also have to keep tabs on the content management team to follow the procurement process and start to understand the framework capabilities of the new CMS product and how to link those to the navigational needs and transactional needs of the final online banking product.

This last team would have a heavy architectural staffing up front and transition to a more development heavy staffing towards the end for delivery. In a perfect world, the project management resources from this team would be the most senior in the organization and consistently work with this team as the skill-set transition occurs.

The below Gantt chart reflects the multiple parallel efforts and when they ultimately need to come together to deliver the final product.

The functional roll-outs would be linked to the customer marketing campaign in order to provide sequential customer communication on new product features as well as permit the new technology “kinks” to be addressed. Also, this allows call centers to ramp up temporary staff to address the increased call volume due to the changes impacting customers familiar with the prior system.

The actual sequence would need to be agreed upon by IT, product and call center management, but potentially the following sequence might fly:

1. Launch the old site with the new branding.
2. After a brief window of time to let the call center call volume return to normal levels, replace the link to current “account balance” information in the read-only system to the same “page” in the new system that requests that same balance through the new middle-ware services. The customer experience would be marginally impacted in that instead of seeing yesterday’s balance details they would be seeing their current account balances. Lastly, address any negative performance or functional kinks.
3. Add account transfer links to the old site that take users to the new site to perform the transactions [first real new customer functionality]
4. Same call center pause.
5. Repeat the sequence for additional transactions such as external account-to-account, bill payment, bill presentment, etc.
6. When all transactions are being handled both UI and middle-ware by the new site and the old site is essentially a set of static pages with links, cut the login process over to the new new site and disable the old site when web logs show no stray bookmarked pages are being accessed. Porting over the authentication system was part of the deliverables of the third Agile team.

Sure, this sounds like a full program of interdependent project activities, but from my experience, banks want to provide highly available and reliable services to their online customers which tend to be their highest revenue generating customers as well. Thus, all of the incremental functional roll-outs which come with the additional cost of testing and program management overhead deliver on the risk adverse, reliable and measured change.

I look forward to all the alternative approaches to this challenges Simon has presented. How far am I from the response norm? Any fundamental flaws?

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.

Build out that Gantt chart

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 put together an initial Gantt chart that lists all the work requests and projects by work phase and indicated which team member is work on which phase. Additionally, your team review of the chart increased its accuracy and improved your team’s level of engagement. This article will build on that initial chart and incorporate work estimation sheets as well as additional work considerations.

Merge Gantt with Work Estimations

Now that you have a list of all work requests and projects with resources assigned by phases plus a quick team review, now is a good time to take all those work estimation sheets and pull the data and plug the data into the Gantt chart. But first, we need to make a few decisions around how to account for time in the day.

If you are using a Gantt charting tool that has an option for defining the work hours in a day, you will need to determine the total number of hours that reflect a true workday for your work requests and projects. As I’ve covered before in part three, realistically, an engineer doesn’t have a full eight hours in a day to dedicate exclusively to project and work requests. With team meetings, HR activities like performance reviews, 1:1’s, training, holidays, time off, etc., your real working hours in a given day maybe more like five of six rather than eight.

If you re using my work estimation template I referred to in part seven of this series, then that template has the ability to incorporate a calculation to handle the real working hours in an average workday. More specifically, the total hour calculations are raw hours where as the “duration” or “contiguous work days” calculations are where the real working hours calculations come into effect. Make sure you are clear on how you are entering your hours for estimating phase durations to make sure you aren’t over or under calculating the length of the durations.

Linking or Sequencing Work Phases

After taking a brief pause and stretching from the cramping associated with all of the data entry you have just completed, now it is time to link or sequence the work phases. Depending on the Gantt chart tool you are using, there should be a way to link the work phases you entered to reflect the workflow over time. Using our example from the previous article, the sequence should reflect that work requests get completed in the following sequence:

Planning -> Design -> Development -> Testing -> Deployment -> Post-Deployment

Below is an example from Microsoft Project that shows this example from above:

Your Gantt chart tool should have some way to indicate that although both tasks can start after the “Design” phase is complete, (hypothetically for example purposes), the Biz development can’t start until a certain milestone is reached in the UI development. Similarly, “Testing” can’t start until both Biz and UI development is completed. In this more complex example, UI is estimated to take a few days more than Biz even though UI started before Biz:

Pause and Admire Your Work

Before you start analyzing the results, first, step back and look at your first draft team resource plan in Gantt chart form. I think you will agree that you now have a single, professional and authoritative report of what your team is currently engaged on work request and project-wise.

Back to Work, Sanity Checking the Chart

Enough basking in your resource management reporting superiority; now it is time to sanity check your chart. Beyond merely double checking that all your “Testing” phases currently appear after any and all “Development” phases, look for these specific abnormalities and take some action on them to improve the quality and accuracy of your chart:

1. Do any of the same resources appear to be working on phases at the same time as phases in another work request or project?

If the answer is “yes” then don’t panic; this might not be wrong. It may reflect a resource winding down on one request and getting started on the next. But, if you have allocated a full “day” on request A and another full “day” on request B with one starting/stopping, you need to be sure that that indeed is the message you want to externally communicate. Please recall that the real goal of this Gantt chart is to “report” to external parties what you want them to see and understand about your team’s work. Thus, if you have been requested to work on two requests concurrently and the skill set needed to complete these two requests is contained within only one team member, then the overlap your report is showing is accurate. It maybe accurate but it might not be realistically achievable. There will be more on how to use this report to assist with rectifying this situation later.

1. Do any resources appear to have large gaps of unassigned work requests?

If the answer is “yes” make sure you have entered all the estimation data correctly and verified your start and end dates. This may not be an error. Rather, this may indicate that a particular resource doesn’t have any formal project of request work to handle during that gap.

Sanity Checking the Chart with your Team

Similar to the previous article, this is another great opportunity to get feedback from your team. As I mentioned prior, in addition to increasing the quality of your chart, you will enjoy the side benefits of over all increased team engagement. If your team is highly technical, asking for feedback might not immediately resonate with them on how this helps them. If you simply ask:

Manager: Does this look right?

Highly Technically Focused Team Member: Yah, sure.

You may need to pull information out of them through more probing questions or consider challenging them on specific data in the report that looks a bit suspicious. Consider:

Manager: Does this look right?

Same Team Member: Yah, sure.

Manager: Ok, it looks like you are working on request 7648 and 7653 at the same time and from your estimates, it looks like both will be done next Friday.

Same Team Member: I can’t do them both at the same time.

Manager: Ok, which one makes sense to work on before the other?

Same Team Member: Oh, I have to do 7653 first since I’ll tweak the solution from 7653 to complete 7648.

Manager: So you need to work on 7653 first, exclusively, and then you can begin work on 7648?

Same Team Member: Yes.

Manager: Great, I‘ll adjust the chart to show that.

Based on the above exchange, adjusting the chart to show request 7653 starting and then ending before 7648 will now more accurately communicate what this team member is working on when and at what date specific work items are estimated to be completed. Additionally, you can note the technical dependency the one request has on the other in order to communicate that externally to interested parties. Lastly, the team member now leaves that conversation with a sense that the boss cares to an increased degree what he or she is working on. Hence another additional up tick in engagement from that team member.

At this point, you should have a rather accurate, through team review, Gantt chart reflecting all the major external work items your team is engaged on. In the next article, I’ll suggest ways to include internal work items like vacations and special assignments that involve your team’s time with considerations on how to reflect that work in amongst the external work in flight to give a even more complete view of your team’s work.

Drag your team into resource planning

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 put together a way to capture work estimation data in a standard format from your team including the benefits to such an approach from a team management perspective. This article will describe how to use the work estimation template for more effective resource planning. I will describe a sequential approach to use the work estimation template data and build a comprehensive team resource plan.

Single Team Resource Plan – Building a Plan

In order to build a resource plan we will steal a data presentation format from Project Management called the Gantt chart. A Gantt chart provides a structured way to represent work break down structures in order to show task start and end dates plus the sequence of tasks with their associated dependencies and assigned resources among other things.

You’ve probably run across project managers on projects creating Gantt charts to a varying degree of detail and not immediately thought this charting could be useful to represent a single view of the work your team is doing. There are various tools, both commercial and open source, that can be used for creating such charts. With a the plethora of choices available to you I would strongly encourage you to leverage whatever your company standard project management tool is for Gantt chart creation. The value of using the same tool as everyone else is to produce a Gantt chart that style-wise is similar to others in your company for easy consumption by your audience. Alternatively, you could ask project managers you work with what they use. Also, feel free to search the Internet for “Gantt chart software” and explore the myriad of choices.

Determine Common Work Request and/or Project Phases

To begin, first determine the best mix of the your company’s standard project management methodology terminology for project phases (“Visio and Scope”, “Pre-Planning”, “Design”, “Development”, “Testing”, etc.) and assign each one a unique color. Below is a sample list phases I will use as an example:

Pink Planning

Purple Design

Red Development

Green Testing

Blue Deployment

Yellow Post-Deployment Support

Remember, the goal of your Gantt chart style resource plan is to easily communicate externally what your team is working on. The more similar the terminology to what everyone else uses the easier for your management and work requesters to quickly grasp what you are trying to communicate. The consistent use of colors for the various project or work request phases helps to easily and visually determine what phase a project or request is in at any given time.

Determine Unique Work Engagements

Add in any unique team work engagement model terms you see benefit in calling out. An example would be if during the formal project “Development” phase your team has a pool of people that can do user interface development as well as another pool that work on business logic component or service development. Try to use as close a naming convention as possible to what the standard project methodology uses. As an example:

Light Red Development – UI

Dark Red Development – Biz

In the case that you have people that can actually work in both groups, using my example above involving UI and Biz development, this resource reporting approach will clearly show who is working on what when. Additionally and possibly more important is the ability to conduct “what if” analysis when a higher priority request arrives. There will be more on the “what if” possibilities later in the series.

Note: One final word of caution, try to avoid creating an incredibly granular work engagement list. A very log list will make keeping the chart up to date a full time job plus it will detract from the simplicity you are striving for in reporting to external parties. Let’s face it; external parties are in a hurry. They don’t particularly need nor care to know your resource A is doing a solution approach review of resource B prior to a full team design review prior to a design committee meeting. They need to know:

• What is in flight at an extremely high level of detail.
• Impacts of a new request hitting your team.

List all Work Requests and Projects

Next, adopt a work request or project naming convention as similar as possible to the one your company uses. If requests have numbers, capture those numbers. If a project has had several name changes, use the most recent but consider indicating the previous names. Enter all the requests or projects you know your team is working on at present as well as all the possible requests or projects that you are aware of that might involve your team. This will be an on going and frequent exercise thus initial list perfection isn’t required. Over time, the list will become more and more accurate and comprehensive.

Enter all your Team Members including Yourself

Most Gantt chart creation tools have a place for entering in “resources” to be assigned to work. Make sure to enter yourself in the likely event that you will be participating materially in listed work at some point.

Enter Work Phases for all the Work Requests and Projects

Yes, now it starts to get a bit tedious. For each work request or project you entered, add the standard work phases you plan to track. You maybe tempted to enter only phases you consider important to reduce the data entry. As you become more experienced at how your resource plan is used in day-to-day resource work handling you may take shortcuts. But, if you are starting out with a new team plan, I strongly suggest to don’t cut corners just yet.

Link Your Resources to the Work they are doing

Now, for each phase entered for each work request or project, enter the resources that will be performing tasks on each of the phases for all the work requests and projects you entered. Don’t worry about start/end dates of phases nor the percentage of time spent on “concurrent” activities for the same team member just yet. I’ll offer some ideas for you to consider on the level of detail and effort you may want to expend in that area.

Review with Team

Now is a great time to have your team members check your work! Consider adding a review of this list at your next 1:1 with each of your team members. You might be a bit surprised to hear what other things your team is being pulled into beyond what you have captured. As a side benefit, you should experience an up tick in engagement from your team now that they know that you care more about what they are actually doing. Plus, they’ll see that the work estimation template exercises are actually going to be used for something beyond just mindless administrivia. By the way, if a team member reports they are working on something but they haven’t previously provided a work estimation sheet for it, now is a great time to ask them to provide one for the work they think is remaining on this unlisted work request.

Now you should have the start of a Gantt chart that captures all the request and project work your team members are working on by work phase of the request or project. You’ve also vetted your chart with your team and increased your team’s level of engagement. Look for the next article in the Single View of the Work series to complete the draft of your Gantt chart by including more data from the work estimation sheets your team is completing.

“You can’t measure it, you can’t manage it.”

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 developed some techniques to get out in front of the requests coming to your team. Now it is time to put together a way to capture that data in a meaningful way that will better reflect what work your team is doing and the impact of new work on in-flight work. This article will describe the benefits of using a work estimation template for collecting this information for more effective resource planning.

Let me start by commenting that I wrote and published the first six articles in this series around the third and fourth quarters of 2009. Since that time, I have been struggling with part seven in that I wasn’t able to succinctly capture a non-company, non-industry specific model that I felt I could share publicly with confidence. Thus, this series stalled at part six. Since that time, I’ve managed additional sets of teams in different industries and now feel I have a solution that is backed by personal experience and ready for public consumption and criticism.

The theme from this series of IT management articles is clearly that there needs to be data collected, documented and modeled to support ones management positions creditably and the ability to successfully commit to executing and delivering quality work. Through personal experience, the size of the company nor the size of the IT department significantly impacts the data model and approach I am proposing:

1. Provide structured and consistent work estimation criteria to your team members.
2. Collect that formal work estimation data into a single team resource plan.

Formal Work Estimate

Avoid the new manager trap of believing you and only you can make accurate work estimates for your team’s services. Force yourself to delegate that work to your team members. This provides a host of benefits, including but not limited to:

1. More accurate estimate based on the skill set of the individual about to do the actual work and not your skill set.
2. Gives team members a sense of empowerment and the ability to have an element of control over their destiny.
3. Builds a capability in your team that allows you to focus on things only you can focus on.
4. Enables more bandwidth for you to be objective in reviewing estimates and providing constructive coaching feedback to team members.

As Peter Drucker (or Robert Kaplan?) is famously quoted: “You can’t measure it, you can’t manage it.”

Many technical people are great at executing technical work but they may not be so great and providing estimates for that work. Thus, one way to accomplish coaching team members is to sit down with them to talk through their original work breakdown estimates compared to the actual time it took them to complete each task. Helping a team member see where they can improve their estimation skills through data points can be extremely helpful since the likelihood future work will be based on current work is relatively high. Having that reference back to past similar work estimates contextually helps in future estimation exercises.

How does one go about creating a formal work estimation template for your team? I’ve recently written about this very topic of formal work estimation and provided a sample spreadsheet as a template for having your various team members provide data back to you in a consistent format for easy review. I encourage you to consider this article as a guide for the first part of this Single View of the Work data model and approach.

Now that your team is using a structured method for estimating work, what is the best way to compile all that data into something meaningful? Look for the next article in the Single View of the Work series to dive into how to construct a single team resource plan that builds on the formal work estimation you have your team providing to you.

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 random sources of 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.

You need to be out in front of the Business and IT

In the first article, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we used a great post by Peter Kretzman to build on a more complicated example surround predicting how much project work your team can reasonably accomplish in the future.

In this article, I’ll apply the same approach but to the “Projects requesting engineering support” request attribute which represents work scenarios where you and your team don’t represent the entire technical solution to the business need. Rather, you and your team contribute a portion of the technical solution to another group that owns the final IT business solution. An example would be along the lines of developing a software module that would be used within the confines of a large software application you and your team don’t own. Another example would be you and your team represent a shared IT infrastructure asset/service or application asset/service that involves integrating your asset/service with a larger more holistic IT solution.

Getting your team engaged when a business problem has been identified and another IT group has been requested to map out a solution that they may decide involves your team’s asset/service is challenging from a predictability perspective to say the least. In these situations, rarely does the IT “solutions” group pro-actively engage you and your team when they get the slightest inclination that a particular business problem they are aware of might need integration services from your team. More than likely, since they are under pressure to provide initial feedback and high level estimates, the required due diligence is cut short. The solutions team falls back on past work your team completed for a somewhat similar but never turns out to be that similar guesstimate on your team’s involvement in their half baked solution.

If you are reading this far and identifying with being more aligned with the solutions group than one providing integration services, then you probably want to focus more on the previous article on capacity planning. If you are identifying with being an integration provider, then keep reading.

If you rely solely on the solutions group as your complete end customer, you will always be playing catch up. Arguments such as “If you had engaged my team earlier in the project life cycle/design phase, we could have partnered to map out a more viable solution” fail to work for some of the following reasons:

• Solutions teams will prefer to by pass the “lack of engagement” discussion rather than participate knowing they indeed didn’t engage your team. What will they do? They will start designing solutions that don’t involve your team’s service. Since they control the requirements, the knowledge and the engagement of peer groups, they can orchestrate a solution that doesn’t involve your team’s service. If you start losing “customers”, at what point will the organization no longer see value in your services and your team in general?

• If a solutions team does participate in a “lack of engagement” discussion and promises to engage you and your team earlier in the process, what is the likelihood that that same team or more importantly, the leadership of that team will be in tact come the next project? You have achieved some level of “I told you so” agreement, but if the players change on the next project, what does that do for you?

• From a management perspective, how many times can you claim you had the “I told you so” speech with the solutions group to no avail to your management before your management will begin to wonder why you are stuck being reactive and haven’t put forth a plan to be more proactive?

So, your options with the solutions group seem limited. You need to provide them with engagement criteria, process and procedural info geared to get them to engage your team ASAP for new solutions. You need to have simple contact lists so they know who to call. Also, you need to participate in some level of “lack of engagement” discussion but with a partnering focus, not an I told you so focus as you run into lack of engagement scenarios. You need to provide all this so you can feel confident you are doing everything you can to empower the solutions group to successfully engage your team. In addition, since the solutions group is your choke point for information and knowledge, you need a strategy to get out in front of the solutions group to level the knowledge playing field.

Get out in front, but doesn’t the solutions group have the organizational charge to successfully interface between the business and IT? Don’t they have the project management heavy resource pool and skill set? Aren’t they the first people the business contacts when they think they need an IT solution? Yes, but as mentioned above, if you don’t make in roads into the business camp, you will forever be playing catch up.

How can you get out in front? Make a strong effort to introduce yourself to all the business folks that commonly engage the IT solutions groups. Bring a very simple and brief one page list of services your team provides, in business language not IT, to leave with them. Get them to spill their role in the organization (product manager, application owner, etc.) to you. Try and get them to share their product or service road map. Ask them about their strategy for upgrades, enhancements, changes in the industry that they are reacting too, etc. Your goal is not to replace the solutions group, rather, ask the questions you wish the solutions groups would ask for you but they never seem to ask. Make sure you stress you are not here to say the solutions group is failing, but rather, you are trying to help the organization, as a whole, better align IT services with business needs. I think you will find that setting the correct tone will open a flood gate of information to help you better understand how your services will most likely be needed in the future.

Now that you have some techniques to get out in front of the requests coming to your team, time to put together a way to capture that data in a meaningful way that will better predict when you will be engaged in work. The next article will show a modified spreadsheet for collecting this information in a metrics and data focused format for more effective resource planning.

Project Portfolio Management Lite

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 random sources of 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, we identified the work request attributes of your team and built a list of sources of those requests.  In the previous article, we covered an example of using the work capacity metrics to support a frequent management question around the lack of project work progress for a team with additional production issue support responsibilities.

So, we have seen how the use of work capacity metrics data can be used to capture the impact of difficult to predict production issue support competing priorities.  Let’s build on that with a more complicated example surround predicting how much project work your team can reasonably accomplish in the future.

A common question to an engineering manager that will be repeated over and over is: “We need to accomplish X and Y and Z … oh, and we need to complete the first Q milestones of project L … can we do all this by the end of the week/quarter/year?”

A completely valid question, but one that is incredibly challenging to answer:  Clearly, the requestor is asking for some degree of confidence that all of this work can be accomplish or if it can’t, what can be reasonably expected and to what level of completion.  Based on the answer, the requestor may consider re-prioritizing the work, or reducing “nice to have” features/capabilities or determining a completely different, potentially non-IT solution to a given problem.  Given an answer of “I don’t know” or “I can’t tell you” or worse “yah, sure we can” without any shred of data to support that claim, the organization as a whole is already heading for a disaster of some magnitude.

Now, any IT project manager reading this is going: “hey, I do this for a living, let me take over …” I agree.  What we are embarking on here is a slimmed down form of project portfolio management.  From the engineering manager’s point of view, you have a fixed set of resources.  You have work requests you have little to no influence over that you have to support.  You also have work for which you have more influence but you probably have more work than you can reasonable staff with a simple: “Hey, Bob, go dedicate 100% of your time to Project X and come back when Project X is done for your next assignment”.

Feel free to type in “project portfolio management” into Google and be prepared for an onslaught of material to sift through.  Try the same in Amazon or even the shelves of your local bookstore and you will find mountains of material on theories and approaches to this topic.  But of all the material available, for someone that is looking for a quick and simple way to put together a mechanism to use some loose metric data to predict the future, I highly recommend Peter Kretzman’s post on his blog “The Practical CIO: Difficulties in project prioritization & selection, part 2” [].

In essence, you need a tool to help you put some metric data you have together with some work estimation data you extract via the requestor to produce some map of the likelihood, given your fixed resources and non-influence-able work requests that you can complete some portion of the work requests by some arbitrary date in the future.  Or, stated another way, what you are trying to predict with data you can explain, the intersection between the number of resources you have, minus the percentage of time they spend on non-project work against the number of projects and associate work duration estimates.  If you take on two many projects at once, your resources will be spread so thin they will predicatively miss deadlines on all of the projects.  If you take on only a few projects but the work is lengthy and sequential in nature (waterfall application development comes to mind) for individual resources, then you will have idle resources but hours and hours of work ahead of the few engaged resources.  As I mentioned above, Peter has put together a straight forward explanation with a simple MS Excel template you can start using immediately which I highly recommend you explore.

After exploring, you should be in better shape to handle the negotiations that ensure when project work requests exceed your team’s delivery capacity.

In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.

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 random sources of 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.

Do you want to go in front of your boss with just your gut?

In the first article, we identified the work request attributes of your team and built a list of sources of those requests.  In the previous article, we dove into team capacity metrics to put some data to the hunches around who is working on what for how long.

So, you have your work request attributes and you have the beginnings of a single model of how your team does work with some numbers to show your team’s real work capacity.  Now let us tackle some way to use those numbers to put some data against those attributes.

Remember from our first article the sample attributes we compiled and determined the level of control or influence you have over the request flow?

Influence:

• Vendor product end-of-life = vendor products that you have purchased and currently use that will ultimately reach a vendor dictated end of life date by which you can no longer get support from the vendor thus you should/have to upgrade
• Vendor product upgrades = instead of the vendor forcing an upgrade due to a product’s end of life, you may need to upgrade a product prior in order to take advantage of new features and functions, etc. you or someone desires
• Service Strategy = the IT service that you provide to the organization needs to keep up with new demands on the features you provide externally as well as the time/energy spent keeping the service functioning internally.  This is greater than just “upgrade to the latest version” but could entail workflow changes, process or procedural changes, etc. that mean some level of work impact to your team.

No Influence:

• Production issue support = ad hoc requests from outside your team for subject matter expertise to assist with resolving system production issues or ad hoc “consulting” such as assisting peers with solving a problem based on your team’s expertise
• Projects requesting engineering support = business sponsored projects that require some resource assistance from your team

Now is where your capacity metrics come in handy to try and be more predictive around the work you have no real influence over.

Production issue support

Looking back at the numbers you have collected about your production issue support, what can you say?  Well, for a given time period, say an average 5 day work week, you should be able to make a data based claim as to the percentage of time your team as a whole spends on this activity.  Is it 5% of your team’s total capacity or more like 30%?  Taking the time captured per the previous article’s approach, you should be able to determine a percentage of total time claim that is supported by data and not just your gut.  The data based rather than gut based doesn’t detract from the value you place on your gut instincts, but rather, should be re-enforcing your notions concerning the impact of this service that your team has to provide.  Consider this management exchange:

Gut Only:

Big Boss: “Why can’t we make consistent traction on the FlimFlam Upgrade project?  Each monthly status meeting seems to show some progress, but never the progress predicted the previous week?”

You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence.”

Gut Reinforced by Capacity Data:

Big Boss: <same question>

You: “Well, we can make some traction but our resources get distracted with production support issues that take precedence.  In fact, over the last N months, in tracking the hours the team devotes to production support issues, the data says the team, on average, is spending 30% of their time focused on production support issues.  Thus, those hours are not available to the FlimFlam Upgrade project.”

I think everyone would agree that the second response has more credibility because it backs up the “gut” with data that puts real context around the impact of the higher priority work requests.  Further, it suggests that only 70% of the work projected for the FlimFlam Upgrade project can actually be accomplished thus closes the gap in the Big Boss’s question around work not getting done.  Said another way, a conservative maximum of 70% of the next month’s predicted work should be expected to be accomplished.  So, now you can add a proactive element to your response to the big boss’s question.  Consider this addition to the above response:

“I would like to propose, unless you disagree, that I contact the project manager on the FlimFlam Upgrade project and ask him/her to forecast the month forward work projection and then a second forecast showing only 70% of that projected work getting accomplished.  That way, we all collectively will have the best projection of how much work will most likely get accomplished given the competing priorities of production support work.”

The data backed gut with proactive forecasting response presents a much more comprehensive answer to the Big Boss’s question than just gut alone.  Plus, going forward, at the FlimFlam Upgrade project meetings, the progress (either greater than or less than 70% in this example) can be tied to the impact of higher priority work requests rather than some nebulous unknown reason that could be left to the interpretation of stakeholders.  More work than the 70% got accomplished?  It must be less production support work.  Less work than 70% got accomplished?  It is more likely to be a spike in production support and not ineffective resources or your weak management of those resources.

In the next article, I’ll apply the same approach to the “Projects requesting engineering support” request attribute.