Midwest IT Survival

We need these ten changes implemented ASAP!

There never seems to be an end in IT, particularly in corporate IT, to balancing competing priorities in the form of seemingly endless work requests.  How many times have you been involved in this typical conversation?

Business: We need these 10 changes implemented as part of this project.

IT: Ok, you put that project on hold a few months back, but we can dust off those 10 changes and get working on them.

Business: How long is it going to take?  Before we put the project on hold it was supposed to take one month of development.

IT: Yes, but a number of other projects have changed the systems involved since the project was put on hold.  We will need to do some analysis and get back to you.

Business: <reluctantly> Ok.

<Analysis occurs amongst technical people and a whiteboard>

IT: In order to meet all 10 requirements, it is going to take two months of development.

Business: What?!?!  Before it was going to take a month, now two months, why double?

IT: Well, because of the FlimFlam upgrade project, we need to rework two of the interfaces in order to meet requirement number 7.

Business: Without requirement number 7, how long would it take?

IT: We’ll need to go back and rework the estimate because the development effort involves meeting requirement number 7.

Business: <clearly frustrated> Ok.

<Re-analysis occurs amongst technical people and a whiteboard to remove requirement #7>

IT: Ok, without requirement number 7, it should only take three weeks.

By this time, all project stakeholders are frustrated with each other.  Tension amongst everyone is high and any misstep going forward has the potential to erupt into a finger point/blame session over tiny deviations from the plan.

Is there anything that can be done to avoid this repetitive negative pattern?

Sure, just implement one of the Agile or Lean methodologies and all your problems go away.  Continuing to use the Waterfall methodology will place you in this situation time and time again.

But what if your organization, as a whole, is not in a position to implement anything but something akin to Waterfall?

One of the major challenges for any manager of project delivery focused resources is project sponsor expectations management.  Unless you are blessed with a very strong project management office, you are most likely stuck with this loathsome duty to some extent.

In your typical corporate project delivery structure, IT is resource constrained compared to all of the work the project sponsors desire.  There exists some process function to try and prioritize the work in some manner (by ROI, revenue generated by business unit, charge back mechanism, etc.)  Even with all this in place, you still have aggressive project sponsors that are trying to keep their goals and objectives marching forward at all costs.  Some partner well with IT.  Some, well, are ever so difficult to keep satisfied.

I can’t say I’ve found the silver bullet that makes the challenges of project sponsors evaporate, but I have found some techniques to reduce the frustration:

Overly communicate on project priority changes

When you find your team members re-directed due to a shift in the priority of projects, take the extra step to remind each project sponsor of the “cost” of this change:

“I just wanted to share that due to the corporate priority committee indicating that the FlimFlam Upgrade project now takes top priority over your project.  Due to this action, any communicated delivery dates for your project are now no longer valid.  Also, since technology will likely change as a result of this shift in priority, your project will need to incur additional time in order to re-evaluate the technical solution and then new dates estimated.”

Don’t assume the project managers will update their project sponsors.

Communicate cross-project impacts regardless of sponsorship

More than likely, your team is a shared pool of resources that is assigned to a variety of projects.  Expecting your project management function to keep track of your resource contentions is hoping against hope.  You are relegated to keeping track of who is working on what for whom and all of the interdependencies between projects. As one project plan gets turned to mush with changing requirements or delays on the business side, feel free to pass that information on to the projects that you team member is also assigned.  Unless you own the project management function, don’t assume the project managers are sharing this type of resource conflict information cross-project.

Communicate Work Breakdowns with Schedules

When working with your team to communicated major dates back to project teams, in additional to communicating estimated delivery dates, also attach work breakdown structures to go along with those estimates.  Make sure to include all possible (realistic) information that might be stressors on making those dates.  You may also want to consider projecting out the work schedule over a calendar.  This way you can add in buffers to handle all of events and activities that cause people to get distracted from focusing on their project work.  I’ve written before about considering a 5 or 6 hour productive work day for your team members.  Or if your team member has an additional assignment to learn new technology or do some cross-training with another team member, factor time for that work into the project work schedule.  A 10 hour blob of work for a given resource may need to be started on a specific Monday and not actually be completed by the end of the day the Friday of that same week.

These considerations are far from guaranteeing a stress free existence for your delivery focused team.  Rather, with enough re-enforcement of the detractors that impact your shared resources from being true dedicated project team members, project sponsors shouldn’t be lacking for information.  This information should reduce the potential for what I call the “surprised and confused” reaction and allow you to focus on your team’s real goal: delivering solid, working technical solutions that meet the project requirements.

Don't give up on the Gantt!

I’ve written before that I am not an “Agile” nor “agile” development nor project management expert. I’ve previously proposed that one by product of “agile” development and project management in general is a reduction in over architect-ed software solutions. With project requirements being represented as stories and tools such as Kanban boards for lean software development to show the flow of work through a process, one might think the classic waterfall project management work and schedule reporting tool, the Gantt chart, is obsolete. Before you abandon this tried and true project schedule reporting solution for the more transparent status inherent in agile project management, you may want to keep reading.

So, you have succeeded in transitioning your IT project management and delivery methodology to one that is more aligned with “agile” than “waterfall”. Your non-IT stakeholders are more engaged than ever in the project requirements definition, prioritization and sprint/release scheduling process. You are tempted to stop trying to use MS Project or other tools to represent schedules in Gantt form. In a word: “don’t”.

One of the main criticisms of complete agile project management is: “The dangers are the loss of recognition that systems/solutions change continually over time as well as team members” Put in more direct, bullet point form from my experience of this criticism expressed by product or management stakeholders:

• What is the big picture?

• I have the big picture in mind, when am I going to get X?

• At the current burn rate, how much time will be invested before I get Y?

• If I add/subtract resources, what will be the impact on the big picture?

These are all criticism subsets that can be directly addressed with the data collection associated with producing a classic Gantt chart. So don’t throw away those Gantt chart creation disciplines just yet.

What is the big picture? I have the big picture in mind, when am I going to get X?

Let the sprint/release iterations continue, but don’t let too much time go by past the releases to meet with the product stakeholders and update your rendition of the product road-map. (You have your road-map, right? You aren’t letting the business surprise you with all requests, right?) This is a great opportunity to get an early indicator if product stakeholders have become caught up in their immediate needs and lost sight of the “cost” of those features. By “cost” I mean the investment in features now means pushing out the product road map. You can gently remind them how the “cost” appears graphically in a Gantt. The Gantt view of their product can clearly show “milestone 45” getting pushed into the next quarter due to their recent feature bonanza. It is much easier to have the “hey, I thought I was getting milestone 45 this quarter” discussion as soon as the schedule shows initial signs of slippage rather then at the start of the next quarter.

At the current burn rate, how much time will be invested before I get Y? If I add/subtract resources, what will be the impact on the big picture?

Here again is where your mastery of tools such as MS Project and the Gantt chart view of the product road map are exceedingly important. If you are working for a MidWestern company, rather than say, a start-up, you can’t ignore traditional budget and resource management constraints. As a start-up in growth mode, your focus is getting your product out the door with the resources you have or your resources plus the on boarding of additional resources. In a MidWestern company, you are most likely trying to maximize the resources you have or being asked to reduce your head count while still meeting project expectations. Thus, prioritizing features to be delivered against a shrinking resource pool is a given. You need something beyond the agile sprints/releases under way to manage project stakeholder expectations on what can be accomplished when.

The Gantt view of the work allows for a graphical view of “if this is more important, what else is impacted” realities. Additionally, add in the need to manage a fixed pool of resources across multiple agile projects and you absolutely have to have some way to represent a view of the prioritized work across all resources. In addition, you may need additional tools to help represent the “what if our team member Sally gets assigned to the VP’s ‘special project’, what does that do to our resource model and what can get done when?”

Conclusion

As an IT manager or IT project lead in a MidWestern company that is moving towards more agile project management and technology delivery, you may be tempted to relax the project management disciplines that come with the more traditional waterfall approach, specifically tracking project schedules in a Gantt chart. In order to avoid the inevitable product stakeholder expectation mismatches as well as pending budget cutbacks and/or uncontrollable resource re-allocations, keep collecting that “program management” data. Continue to have re-occurring meetings to review the “big picture” Gantt chart view of the work and use other tools to reflect “what if” scenarios and their impact on the big picture.

Over Architected?

First off, I am by no means an “Agile” (nor even “agile” with a small “a”) software development expert.  There are many more individuals out there that are way more experienced and in a much better position to speak authoritatively about the Agile methodology and its associated principles on driving efficient and effective software development.  A few blogs where I consistently find great Agile perspectives are included at the end of this article.  But as I’ve participated in Agile and agile-like development efforts over the years, I’m finding an interesting pattern.  Agile and agile-like approaches have a positive by product of reducing the occurrence of over architect-ed software solutions. Over architect-ed solutions put stress on the delivery of a software application project as well as drive up the cost of software development and maintenance, in general, disproportionately to the business value produced.

As an example, a sample development effort starts out with:

Product: “We need a super widget in the product by next release, can we have that?”

Project: “We are going to need detailed requirements for the super widget in order to start developing it.”

Product: “Oh, it needs to be able to interface with the dry cleaners to know when it is time to pick up the laundry as well as make coffee for the customer before they get out of bed in the morning.  Basically the same features as our competitor’s recent release, but with these additional benefits. <Or some other description that is actionable at a high level, but lacks the detailed requirements needed to feed a development team with actionable development tasks>”

Development: “Ok, we’ll get started since we don’t have much time before the code freeze for the next release.”

… Time goes by …

A project status meeting occurs sometime in the future.

Product: “So, where are we with that super widget?”

Development: “We have the basic framework setup but it isn’t going to have all the features working by the next release.”

Product: “But I thought …”

Development: “But you said …”

Project: “What happened?  How come we are X days from the code freeze and we don’t have a viable solution?  I thought …”

Now sure, this isn’t the most perfect example of capturing how the requirements drift between stakeholders leads into an over architect-ed solution, but hopefully you get the scenario.  Or possibly another example would be when a solution is developed and released into the production environment.  Extending the example above, weeks later, when enhancements, tweaks or feature extensions are requested, a tense conversation occurs around:

Product: “But I thought the super widget would do X?  How come I am hearing it will take 30 hours of development to get X?  The testing cycle is already elongated due to the complexity of the super widget thus I thought it included X?”

Development: “But we said that the framework would support X, but we never said X would actually function without more development!  We developed the super widget to do W, Y and Z but only stubbed out X.”

Project: “But according to the requirements, it says X should be …”

And yes, an argument can be made that if:

• more effective requirements gathering occurred
• more effective project management captures more depth of what would be developed and available when
• more effective product management defines a more exhaustive product feature road map that more clearly outlines what would be available and not available when, feature-wise

… These problems wouldn’t have occurred.  But the nature of an agile-like approach puts a tighter focus on all the stakeholders:

Product: They can share the “overall vision” of what they ultimately desire the product to do, but they are forced to consider what they really need within the shorter duration of the agile-like release schedule.  Thus, product walks away with a clearer picture of what they are really getting in the next release.

Development: They get the benefit of the product’s “overall vision”, yet, they get to quickly dive into the critical features and start the dialog of how long different feature components will take to develop.  Thus, development knows exactly what they need to do now for the next release, yet they benefit from knowing where this product feature is going in the future.

Project: As long as they keep the product and development stakeholders talking about granularly defining what needs to really be built by when, the project management function has much greater clarity into what is going on and what details to track.

From what I am observing, all of the above create a stakeholder forum of information sharing that reduces the likelihood that an over architect-ed application will get developed. Most importantly, instead of leaving the feature set open and vague enough to allow a creative and motivated development team to start building and building and building only to re-surface with a highly complex solution to a loosely defined problem or need, it brings more cohesion between what is really needed first.  Once the “first” has been built, the “seconds” and “thirds” get built inline with the product roadmap.

In researching this theory, I wasn’t able to find any articles that linked agile-like development efforts to a direct reduction in software over architect-ing.  This article entitled “Agile Architecture: Strategies for Scaling Agile Development” had some interesting content on baking architecture into an agile-like effort.

Anyone else have any direct experience in agile-like compared to waterfall-like development efforts yielding less application over architecture?  Can anyone share any links to good web articles on this topic?

Agile related blogs I follow:

David’s Software Development Survival Guide

http://softwaresurvival.blogspot.com/

NOOP.NL

http://www.noop.nl/

Software Project Management

http://blog.brodzinski.com/

fragile

http://fragile.org.uk/

Regular Geek

http://regulargeek.com/

Critical Results

http://criticalresults.com/