Home | Login | Recent Changes | Search | All Pages | Help

FantasySchedules

Fantasy schedules (FaS) is a disease. When I'm asked for help, I like to treat this project disease. I feel good about my tools for treating FaS at the individual and team level. My skills are less developed at treating the disease at the organization level. I would like your help with how to intervene at the organizational level.

Situation: A large IT organization supplies services to the company's business units. The company's strategy is to grow by acquisition. They have quickly bought a lot of smaller companies, which all perform the same basic business function. Although the company is still acquiring, it's moving at a much slower pace. The executives focus seems to have shifted to consolidating the business.

Until now, company management has expected little from the internal IT organization. Almost all of the IT functions were outsourced to a large supplier. That decision was expensive and didn't improve service. A new CIO was hired last year and decided that he can save a boat load of money by moving away from outsourcing. So, he has reduced outsourcing to a minority position and is building a new IT organization virtually from scratch.

The CIO has been there a year, promised a lot and hasn't delivered much yet. The CIO must be good at spinning stories because the company management whose opinion counts the most still like him.

I see an IT organization that is a mess. Everyone is overloaded. Problems are holes that people keep falling into again and again because they are neither defined nor resolved. Project success depends on getting the right individual's involved. The CIO wants to buy monitoring packages so he can get things under control. This organization fits the pattern of a variable culture as well as I've ever seen.

The discontent of the business units is beginning to show. They aren't getting the results they need. The people in the IT organization cope by placating them. The IT people promise the fast delivery of new systems. The IT organization doesn't have the process nor the skills to handle a large number of complex requests. But, that's what they are getting.

So, the FaS disease spreads. Each supplier level in the IT organization tacitly agrees to the FaS. They don't want to be the team that is blamed for the failure to give the business unit customer what they need. Good people work long hours and continue to fall into the same holes as they did on previous projects.

IT management recognizes that they have a problem, but they don't know what to do. They ask their partners (outside suppliers) for help. The sales person for the supplier I work asked for my help because he knows that I'm a rare bird -- someone who knows about both technology and management.

I've worked with this IT organization on four projects so I've had a birds eye view of the dysfunction. I've talked to middle IT management and, so far, have proposed two interventions. The first is a dashboard for the department my company works with the most. The second proposal was for a project retrospective.

Middle management accepted the first proposal. I suspect the acceptance was because I had created something they could roll out immediately. Middle management told me that would have to think about the project retrospective proposal. They were troubled by my condition that the retrospective had to be done as a face-to-face meeting rather than a conference call. I stood tall on that requirement.

I believe that the two proposed intervention will be effective at the team and individual level. The retrospectives would help treat the FaS disease. But, that proposal doesn't seem like it's enough. And, I keep wondering what's really needed at the organizational level.

My first question to you is --

• What successful FaS treatments have you experienced?

If you could propose things to the CIO --

• What concrete actions would you suggest?
  
  
• How would the IT department benefit?

SteveSmith 2002.07.27

Yes, I agree that working at the middle management level won't work. Thank you for reminding me of the importance of that fact. -Steve

Yes, please tell me more about how you would structure a change management plan. -Steve

New functions may need to be put in place, such as a Program Office, if projects overlap in customer area or data or process. New roles may need to be defined, such as an IT relationship manager for a division. And new processes may need to be put in place, such as Portfolio Management....in IT this is managing the load of projects effectively against the resources and benefits. The benefits are weighed across the entire portfolio and balanced against cost and resource availability.

They have a PMO. From what I can see, they are infected with FaS. -Steve

Additionally, project management may have to be more structured to manage the complexity. Processes to review work 'across customer lines' may need to be intstituted.

None of these is a quick fix. And, ALL of these require the partnering with the division business users.

There is no quick fix, but that's what I hear them wanting. -Steve

If I were the CIO, I would start by telling the IT and user community where we are now (be honest), where we are going, how we are going to get there, how long it will take (be honest), and what my expectations are for all of them. So, there's the outline of the plan <grin>.

Honesty? Whoa. I keep remembering Jack Nicholson saying, "You can't handle the truth" in the movie A Few Good Men. FaS is medicine for people who can't take the truth. -Steve

There need to be leaders for each area (program office, project mgmt, process) and the teams peopled with both IT and users. Then, get to work!

How do you change survivors into leaders? -Steve

Of course, you wouldn't want to do these all at once! MarieBenesh 2002.07.27

In-House. -Steve

For the situation of FaS in your own organization, where you may be around for a while, the cure might involve charging managers for overtime used. This metric shows who is playing "Spanish Theory Manager" using "Free Overtime!" from the troops. If managers are rated by how much overtime they consume, the dynamic of the metric will start normalizing the schedules.

Bob, Nice! That's an excellent metric and, properly used, an excellent intervention. -Steve

Unless you are an OD or Mgmt. Consultant, I can't see you getting this idea sold - your clients are too low to make the metric stick.

Yes, you are right. I see a consensus developing.<g> -Steve

I would assume from your discussion that the managers involved feel no pain whatsoever from inflicting overtime via FaS.

For now, no, the managers seem to be able to get away with it. -Steve

BobLee 2002.07.27

It's the CIO's problem. -Steve

And, it's clearly not your problem, so figure out whose it is and take it to them. If they ask you for help, refer them to professional helpers who are paid to do the job. You are not being paid to do this job, and so your advice is going to be worth what they're paying for it.

Nope, it's not my problem. I never thought it was. Nevertheless, I'm fascinated with the problem. I'm exploring. You have made it crystal clear they need to pay someone to help them. I agree. Funny, It seems to me like a classic situation where the company may put itself into a dependent relationship with any supplier that gives them a quick fix. Lots of suppliers are happy to give a customer all the dependent voodoo they can muster. -Steve

Maybe you could convince some of them to participate in the AYE Conference. We have several sessions that could help them a lot, and it would be a lot cheaper than bringing in professional help, like a few of the AYE hosts and participants I could think of. But get yourself out of the middle of this.

I hope I'm not in the middle. I'll think about that notion. I'll follow up with inviting people to the AYE conference. It's the right thing to do. -Steve

- JerryWeinberg 2002.07.27

This turnaround had support from the top, but happened from the bottom. One of the triggering events was when people at the bottom saw someone stand up and speak a truth ("I don't know if this schedule is realistic") and not get shot. That got the attention of people on the team, who'd felt shut out of the planning process, and didn't feel safe doing anything other than nodding when the schedule was discussed in public.

The next step was a mid-term retrospective/prospective, which gave the team a chance to express a bunch of stuff they hadn't felt safe talking about (venting), as well as talking about ways to move forward. With a team of 7, this took 2 days (1 day would not have been enough). The team went in demoralized, and came out charged up, which suprised management. There followed a six week, management supported schedule reset, where we dug into requirements, redid bits of analysis, did some prototyping, and reprioritized the work ahead, and built a schedule that the team signed up for.

Things could have happened very differently. If the first person to publicly challenge the schedule had been beheaded, heads might have stayed down, and the fantasy would have continued. If the team didn't get a chance to vent, they might move forward grudgingly, at best. If the team didn't get a chance to contribute their ideas into planning a turnaround, they probably wouldn't have given their full efforts and energy to supporting someone else's turnaround plan. If management hadn't given support to a period to stop and replan, the team probably wouldn't have arrived at a schedule that they could support.

DaveSmith, 2002.07.30

Don't let any good deed, like being realistic, go unpunished. Here is what an internal person told me about the level of infection in the PMO group:

Oh yeah. Shortly after I started, a PM was removed from my project. It looked to some of us (developers) that he was removed for giving the wrong answer to the question, "When will this be done." Ironically, it currently looks like the project may wrap up about where he predicted it would. Pretty remarkable since he was making the prediction without requirements. The PM that replaced him was willing to agree to the end of this month (back whenever) while telling the programmers to shoot for the end of next month. Neither of which were attainable. He did a pretty good dance of redefining what we agreed to deliver when after the fact.

SteveSmith 2002.07.31

I'm often, as an outsider, the person that stands up and speaks the truth about projects. I'm going through this right now with a client, and so far it's taking exactly the path that Dave Smith describes. Part of the secret is not to stand up too soon, and gather as clear evidence as you can before going public. My intuition after 45 years tells me a lot of stuff way before I can explain it to others, but it's not a good idea just to have them do things just "because Jerry says so." - JerryWeinberg 2002.07.31

Steve, I'd tell them first to check their bank account and other sources of income (like a working spouse). Then update your resume and look at what's available in town. Then, if you still have confidence that you'll survive no matter how badly they take the truth, assemble your facts. Dave Smith's story, below, is a good example of how to do this. Make things visible and explicit. Then present it to the right people, in the right environment, and if they fire you, know that it was the best thing that could have happened to you under the circumstances. - Jerry

Jerry, Agreed. Your repsonse is even better worded than I anticipated.

So, as you have shared with me many times, some level of financial independence is always important. Let me synthesize another thought: In situations like FaS, understanding the epidemic and having treatments is insufficient. You must have enough self-esteem and, just as importantly, safety to share what you know. You can create safety by having the means to support yourself in the event that your employer can't tolerate the difference between his or her fantasy and your knowledge.

SteveSmith 2002.08.02

Marie, I look forward to reading it.

SteveSmith 2002.08.01

The immediate response was "That's too long!" which I responsed to by grabbing the product (marketing) manager, hauling him over to the board, and asking him what he was willing to drop. After a struggle, he agreed to defer about 15 person weeks of work (out of ~350). Sales squawked, but I'd hand them the product manager. (The "this is taking too long! but don't you dare drop anything we've promised to customers!" arguments were pretty funny.) Meanwhile, as developers were finishing work, they would cross out the corresponding post-it (with a bright red pen), so we had very visible evidence of progress, in a hallway that most of the execs walked down at least twice a day. We shipped within a week of the whiteboard prediction.

This worked because we had a relatively small (25 person) project, with everyone, including execs, in the same building. It also worked because we had a visible, living schedule that everyone could touch. People put their own post-its up, and could cross them off when they were done. With nobody making promises on their behalf, people made (and kept) their own promised. And most execs had to walk by it at least twice a day, so it was hard to ignore.

I don't know how to scale this, (though it would probably involve digital pictures of each team's timeline on an internal website). I suspect that if even if each group kept such a visible timeline, vitality would be lost if the result were filtered upwards through a paper project plan seen only by people in another building. A project plan on paper is easy to play fantasy games with if the people whose names are in the little boxes aren't looking on.

DaveSmith 2002.08.01

Dave, Thank you. You've told me that story before and it's every bit as good in the written version. I would love to see you turn the story into an article.

SteveSmith 2002.08.02

A cure for Fantasy schedules at the project level is the Planning Game from XP -- that is Release Planning, and updates to the Release Plan throughout the project during each iteration's Iteration Planning meetings. (This is similar to Scrum's Project Backlog and Sprint Backlog.

The question is whether managers at higher levels understand this.

Pete McBreen says that CommandAndControl organizations tend not to listen to estimates from the programmers, and the Planning Game requires a strict separation of responsibilties -- business (Customer) requests features and programmers make estimates.

• http://c2.com/cgi/wiki?PlanningGame
• http://www.extremeprogramming.org/rules/commit.html
• http://www.extremeprogramming.org/rules/iterationplanning.html

--KeithRay 2002.08.03

SteveSmith 2002.08.03

Putting features requests and estimates on index cards, that people can pick up, move around, stack and re-stack, and so on, makes Release Planning meetings go smoother than if the feature lists are on a single sheet of paper...

Some people lay out the index cards left - to - right per value, and then bucket them up into iterations. (And this can be re-done each iteration, to account for changing priorities and mis-estimates.)

Some people use index cards of three sizes, corresponding to their estimates (which, in the most abstract case are "story points" of size 1, 2, or 3, rather than "ideal days" suggested in the first XP book.).

Outside of meetings, the index cards (with markings to indicate completion) could go on a cork-board as a Big Visible Chart / Information Radiator -- usually just the ones for the current iteration, or sometimes current and previous iterations.

The Extreme Hour is basically a simulation of the planning game and subsequent tracking of progress for two or so iterations. JeffMcKenna has suggested doing an "Extreme Hour" if people are interested. I'm thinking this might be appropriate for the SHAPE day...

http://c2.com/cgi/wiki?ExtremeHour

--KeithRay 2002.08.04