Joe was in a good mood when he walked into the meeting with his Process Management leads for the first time.  Perhaps is was because Selina had just walked him through a consistent process for tracking and managing project information that didn’t keep everyone in “fire fighting mode” all month long.  “Orderly is good,” he used to say, and he believed it.  Ever since coming to this IT group, Joe has had a series of “rude awakenings” about their totally different way of delivering software.  This day was a good day.

That mood was about to change.

(Authors note: this is the third and final installment in a series of articles on Joe Freeflier, a new IT manager taking over a SOA+BPM driven IT group.  See Part 1 and Part 2 ).

When Joe sat down, he met his three process leads.  There was one for each business area that he worked with: Sales, Marketing, and Public Relations.  They were very different business areas, yet they maintained a very nicely integrated portal that all of their professionals, internal and external, used to do their work. 

After a round of introductions, Joe asked if they had project status available in the same portal that the shared services team used.  When they answered in the affirmative, Joe opened up the portal to look at the Marketing team’s project list, and stopped dead in his tracks.

There was one project.  The end date was the end of the fiscal year.  The budget was large enough to pay for the salary of every person in the team. 

Joe turned to Tom Rankle, head of the Marketing process team and asked for a rundown of project status and deliverables.

“Well, Joe, we don’t manage our team by project status and deliverables.  We manage by customer value points.  We have delivered 61 value points to the Marketing team this month through the updates to the advertising platform workflow and the new reporting interface for Marketing management.  That puts us right on target for delivery for the quarter.” 

“Customer Sat is running at 80% and our delivery backlog is sitting at an optimum level of six weeks of likely work.  Team morale is high, and our overtime ratio has been kept under 5% for the fifth month in a row.  Our current risks are that the new lead entry service update won’t ship in November, which would slip our updates to the event interface by two months.  Shared services has posted the risk as “yellow” so we are releasing the event update without the new service.  We will revisit it in the spring, after the big winter conferences.

I’d say we are pretty healthy.”  Tom finished by handing a small set of papers to Joe with all of these points in nice graphical format, showing steady values or steady trends. 

Joe was immediately lost. 

Where was the list of projects?  Where were the budgets and deliverable dates and change control processes?  The bug report triages, and the eternal fights over project scope? 

“Back up, Tom.”  Joe had to admit to his leaders that he wasn’t following the thread.  “I’m not sure I’m with you.  Can you walk me through the way your teams work?”

Marcie jumped in.  She was Tom’s peer, running the Sales process team.

“Let me give you some history…

“About two years ago, we were in a bind.  Our projects were always late.  Our customers were complaining all the time.  Every project was questioned, challenged, picked apart.  We would say something would cost 1 million, and the customer would say “you have half that.”  Most of the code was brittle, and team morale had gone below “low” to a kind of political viciousness… the most senior folks got to write new code, while the new guys always had to maintain the junk. 

“Then Michaela brought in the SOA and BPM guys.  We split IT up into shared services and process teams.  Our teams write the process bits.  We do workflows in the workflow management system, and we write the user interfaces.  The shared services team (or SST) provides data through services.  We own NONE of the data ourselves. 

“As a result, the stuff that changed most frequently, process and user interface, moved to our teams, while the stuff that needed to be stable (data and information management) remained with SST.  By breaking things up this way, the process teams could specialize on one thing: quick continuous improvement.

“We looked at our value chain.  You know that all of the process folks moved over here, and we had come from a lot of different traditions: Kaizen, Lean Manufacturing, Six Sigma… We all wanted to use our own process tools to solve our own problems.

“We found that the value of careful change control processes drops dramatically when the team writing the code cannot screw up the database.  We call services, and the services protect the database.  Well kinda.  It isn’t perfect, but it works fairly well.

“So we moved to an “agile development” model.  We take small teams, give them a list of features, and ask them to deliver value at the end of the month.  Each feature has “value points” assigned by the business.  We are measured on the maximum number of value points we deliver each month.” 

Marcie stopped and took a drink from her water bottle.  Then she jumped right back in.

“What we stopped doing: big analysis and planning projects.  In fact, all notions of ‘big planning’ are absent.  We let the Strategy and Planning worry about that stuff.  We just focus on delivering small, well-tuned, changes to the processes.  We measure key indicators before and after each process change. We make the changes using process management tools, not reams of complex code.  The most complex things we write are U/I code.

“These days, the users have started writing their own code using our mashup interface in Sharepoint.  It’s reduced some of the strain for small fixes and helps the customers feel “bought in” to the whole idea of using processes and services to define IT.

“So when Tom talked about his status, he was giving you the measurables that we manage by.  We care about value points, so we are always working to increase the number of value points we can deliver each month.  If we do our job well, customer satisfaction goes up.  So far, we’ve found that we can push the delivery of value points higher, but the quality drops and so does satisfaction.  So we don’t measure by value points alone.  We aim for a target “customer satisfaction rating” of 80% every month.  Tom has been nailing it consistently.

“One other thing we found is that the amount of overtime that the teams are working is a major driver of dissatisfaction.  Team members leave when you make them consistently work overtime.  So we capture the number of “forced overtime” hours per month, weight it towards the developers, and try to keep it low.  We find that does a good job of keeping morale high.  Staff turnover has dropped off dramatically since we started this plan.

“And when a service has to be changed, we involve the Shared Services team.  We collect the information and process needs, and the Shared Services team designs the service changes.  Sometimes it is simple, but often these changes are difficult, and they occasionally slip.  We find ways to deliver value anyway, which keeps our customers happy, even if we can’t deliver things in a predictable order. 

“The backlog is a measure of the amount of work that the business wants to have done.  We try to keep about six weeks in the queue at any time.  That way, if a shared service slips off the current cycle, we have useful and valuable work for our teams to do while they wait.  It is all described in terms of features, dozens of small changes that can be done fairly independently.”  Another drink of water, and she stopped talking. 

Joe took a minute to let it sink in.  What he was witnessing was a totally new way to “do Information Technology.”  These teams were not built the same way that his prior IT teams had been, and they were not fighting the same fights.  But they had solved the biggest problems that he had been facing: how to deliver value to the business customers on a regular basis.

The answer is here: combining Business Process Management with Agile Development in business-facing process teams. 

Finally Joe was getting it.  SOA is not about services.  It is about empowering a new way to deliver value. 

As the meeting proceeded, and Joe listened intently to the numbers that each team was delivering on, his mind kept wandering to his past IT teams.  “I wonder why we didn’t do this earlier?” 

He resolved to place two phone calls.  One to his replacement in his prior group, to invite him over to see this.  The other to Michaela… to thank her.

(authors note: this is the last of a three part series on Tom Freeflier.  See Part one and Part two).

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “The New Life of Joe – Part Three – The Users Are Coming!”
  1. Nick,

    Of all your great thought leading posts on the technical nature of SOA, I believe this series illuminates the biggest challenge to SOA success in most organizations.

    Overcoming the over 30 year practice of traditional IT project management to adopt the style of delivery you describe in the "The new life of Joe" will take thought leadership on the PM side I do not see being discussed in the IT community.

    I think the fact that you received hardly any comments on this series points to the chasm that needs to be crossed before this can become mainstream thinking by IT management.

    Thanks again for this great series.


Leave a Reply

Your email address will not be published. Required fields are marked *

two × one =

This site uses Akismet to reduce spam. Learn how your comment data is processed.