Thursday, July 27, 2006

Leading a Software Project Like Directing a Movie?

A couple of weeks ago a co-worker passed me an article that really got me thinking about what it takes to lead a significant software development project. In Successful software management style: Steering and balance* Walker Royce, Vice President Rational Brand Services, makes an interesting argument that running a major software project is a creative act, more like directing a movie than what most of us think of when we think of project management.

I must admit his argument is seductive. I think that as an architect, I consider myself more of a “creative type” who makes something out of nothing. Often I don’t like being held to a plan I had no part in making. And when I help make a plan, I budget some time for some tinkering.

Maybe Walker Royce has a point. Here are some quotes:

“Managing software projects successfully has proven to be very failure prone when using the traditional engineering management discipline. Comparing the challenge of software management to that of producing a major motion picture exposes some interesting perspectives. Both management problems are concerned with developing a complex piece of integrated intellectual property with constraints that are predominantly economic. This article introduces some comparisons between managing a software production and managing a movie production, then elaborates four software management practices observed from successful projects. The overall recommendation is to use a steering leadership style rather than the detailed plan-and-track leadership style encouraged by conventional wisdom.”

""Heresy!" some may shout. "Software projects need more disciplined engineering management, not less." Before you dismiss my claim as an insult to the profession, consider these observations:

  • Most software professionals have no laws of physics, or properties of materials, to constrain their problems or solutions. They are bound only by human imagination, economic constraints, and platform performance once they get something executable. Some developers of embedded software are the obvious exception.
  • In a software project, you can change almost anything at any time: plans, people, funding, milestones, requirements, designs, tests. Requirements -- probably the most misused word in our industry -- rarely describe anything that is truly required. Nearly everything is negotiable. "

"Metrics and measures for software products have no atomic units. Economic performance more typical in service industries (value as observed by the users vs. cost of production) has proven to be the best measure of success. Most aspects of quality are very subjective, such as maintainability, reliability, and usability."

"Process rigor should be much like the force of gravity: the closer you are to a product release, the stronger the influence of process, tools, and instrumentation on the day-to-day activities of the workforce. The farther you are from a release date, the weaker the influence. This axiom seems to be completely missing, or at least grossly underemphasized, by the process evangelists and literature, but it is usually very observable in successful software projects."

"Most unsuccessful projects exhibit one of these characteristics:

  • Over-engineering on the early phases (creative aspects) of the life cycle. You need maneuverable processes that easily adapt to discovery and accommodate a degree of uncertainty to attack a few major risk items, prototype solutions, and build early and coarse artifacts. What creative discipline can you think of in which more process rigor is considered beneficial in helping humans think?
  • Under-engineering on the later phases (production aspects) of the life cycle. Extensive change-managed baselines of detailed and elaborate artifacts need engineering processes with insightful instrumentation and attention to detailed consistency and completeness to converge on a quality product."

On the flip side, there is the problem of “Can my customer culturally handle the kind of “give and take” in a creative software development process? Do they understand the idea of “discovery” of requirements or do they think they've identified them all already? Can customers really admit how little they know about what they want or how poorly they sometimes articulate their “requirements”. Can they accept trying out an idea, deciding it was all that good, and throwing the work away?

Another problem area is that for most of us is that we have to live within a budget which often must be cast in stone very, very early in the process before those requirements (negotiable as they may be) are really well understood. How many customers really work in an organization that allows them to “go back to the well” and ask for more money without commiting some kind of career suicide?

Then there is the recurring problem of technical orgainzations expecting to have their budget estimates cut so they pad their numbers. Business users then come to expect to routinely receive padded numbers and promptly cut the estimate by an even larger percentage. For a humorous look at this situation see Project Approval Games: Three Fantasies mentioned in a previous post Feudal Line Management and Shared Resources.

My gut tells me to accept a lot of Walker Royce’s ideas and bake them into a project plan that appears more traditional by adding a lot of tasks with formal sounding names that really mean “verify we really understand what they want”. My experience is that customers often articulate pretty well the “happy path” of what they want when everything works like they hope. They are not so good, however, at telling you how many things can go wrong and telling us what the software should do when an exception occurs and we are no longer on the “happy path”. It may be wise to add a few formal sounding task names that really mean “contingency for exception handling we don’t know about yet goes here”.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Wednesday, July 26, 2006

Hot Skills / Cold Skills - What's the Near-Term I/T Future?

I’m sure I am not the only technical professional who has pondered questions like:

  • Are my skills becoming obsolete?
  • Am I becoming too expensive to do the things I’m good at or like to do?
  • What kind of skills do I need to develop to stay gainfully employed? (keep from getting fired - play defense)
  • What kind of skills do I need to thrive in the future? (get promoted - play offense)
I stumbled across a ComputerWorld article by Stacy Collett entitled “Hot Skills, Cold Skills: The IT worker of 2010 won't be a technology guru but rather a 'versatilist.'

In the article she has some interesting quotes such as:
  • “The most sought-after corporate IT workers in 2010 may be those with no deep-seated technical skills at all.”
  • “IT departments will be populated with "versatilists" -- those with a technology background who also know the business sector inside and out, can architect and carry out IT plans that will add business value, and can cultivate relationships both inside and outside the company.”
  • “the skills required to land these future technical roles will be honed outside of IT. Some of these skills will come from artistic talents, math excellence or even a knack for public speaking -- producing a combination of skills not commonly seen in the IT realm.”
Check out the article. I’d love to hear from others about what skills they think it will take to “play offense” and thrive as an I/T Architect in the near future.

Also, for anyone who has had their head in the sand, you may want to see these for a little motivation to consider the future. (hint) Both of these are focused on the latest and greatest SOA technology, not legacy code.

You may also want to check out some of my previous posts which address similar issues related to our changing and evolving careers:

The Globalized I/T Architect

I Really Am a Master Certified I/T Architect

Are All the Good I/T, Science, and Engineering Jobs Going Overseas?

The Role of the Business Transformation Architect

A Culture of Innovation? Or NOT?

How to Become More Creative in Solving Problems

$1 Billion Investment in "Info on Demand"

Are you Pi-shaped?

Epidemic Career Advice

SAP Disrupts Everything

Naming Well, an Essential Skill of an I/T Architect

Vendor-Neutral I/T Architect Certification Program

I/T Architect Certification Revisited

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Tuesday, July 18, 2006

What's in a Name? SAP Gives Up on ESA and Adopts SOA Terminology

I heard today that SAP was abandoning their name "Enterprise Services Architecture" name (see this ESA post from 2004 and Breaking Down SAP's ESA Strategy) in favor of the more widely used term Service-Oriented Architecture (SOA). I decided to do a little Googling tonight to check it out. I could find no official announcement about the name change (I didn't look all that long) but many of the top ranked search results now seem to come back with the term "Enterprise SOA" (see SAP's Enterprise SOA Adoption Program). It is a little amusing that on one SAP page pointing readers to white papers, both terms are used.

I don't know how significant this really is, but it appears they are grudgingly adopting the terminology everyone else is using.

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Wednesday, July 05, 2006

Feudal Line Management and Shared Resources

There is often a fuzzy line in practice between the role of a project manager and an I/T architect. I say in practice because all too often it is not possible to be a “pure” I/T architect. We have to help the project manager be successful if we want to continue to have our fun creating new solutions to solve new problems.

I know, for example, that my project managers often rely on me for help setting up a viable project plan. How are they supposed to know which tasks in the technology mix are predecessors of others if the I/T Architect doesn’t tell him? And since all of my projects have at least some first-of-a-kind (with the client anyway) element to them, how would the project manager know what the tasks are in the first place.

Then there are the resource issues. If the first-of-a-kindness of the project involves some development tool or middleware that we haven’t used before then a good I/T Architect should help the project manager identify the skills required. I know once names are submitted, I often get involved in the interview and selection process as well.

One of my project manager friends and I were discussing a common project management problem – the resource that everybody needs for their project. In our case, we are anticipating that if our client adopts SAP then the already thin ranks of the programmers supporting the legacy systems will be in great demand. Who will provide the routine support if these people are in requirements discussions related to SAP? Who will create that urgently needed report if they are in a conference room trying to help the data migration team move the legacy transaction history over to SAP? What if the client’s business climate becomes more competitive and the business requires yet another tweak to the legacy system to support the latest marketing program? But there are all those SAP meetings to go to!

We came to the quick conclusion that the client could hire 20 or 50 or 100 SAP consultants (or another 250 in India) and not deliver a working SAP instance any faster because those few legacy subject matter experts (SMEs) could only attend just so many hours a day of meetings.

My project manager friend pointed me to a set of really wonderful project management “fables” which uses the feudal system of middle age Europe and the story of Robin Hood to illustrate the real-world, political problems faced by today’s project managers in a the resource constrained realm of shared resources. Check out Robin Hood PMs and Feudal Line Management by Dick Billows at This article makes some great points and is amusing reading and all too true! A small sample of this gem:

“Sure, there were all those blasé assurances of “full support” from the line managers before the project started. Now that the work has begun, these feudal Sheriffs of Nottingham patrol their castle walls hurling stones and boiling oil on PMs who attempt to utilize one of their artisans.....’A person can have but one boss and that is I.’.... the sheriff notes the PM’s project work assignment on a scrap of paper but does not assign a specific individual from the castle to complete the task. ... They (the PM) don’t know who will be working on the assignment When the sheriff finally does allow work to start, the selected individual is usually not the most skilled artisan in the castle. Often, the sheriff picks an individual whose absence from the castle may actually improve the castle. .... The sheriff may recall them on a whim or to silence another whining Robin Hood. How does the borrowed person react to all this? It’s clear that the project assignments should not, in any way, interfere with the person’s accountabilities in the castle. It’s there after all, that the sheriff will decide on compensation, promotion and continuing employment. The PM has none of these rewards to dole out... With several borrowed people on the team, usually on critical path assignments, the project team takes on an excessively casual, holiday-like atmosphere. This is in stark counterpoint to the user or client King who views the project as a crusade and reminds the PM of its importance at annoying frequent intervals.”

Another gem from the same site, Project Approval Games: Three Fantasies where the fantasies are Executive Fantasy Land (too much confidence in the PM), the Used Car Lot (PM as “slick shyster” trying to rip the executive off), and The Eager Puppy Dog (which drives PMs to pad their project estimates with contingency and executives to assume there is extra fat which can be cut).

Read both and enjoy!

Copyright © 2006 by Philip Hartman - All Rights Reserved

The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions.

Back from a Blogging Hiatus

I am hopefully back from a long blogging hiatus. Things just got a little crazy for a couple of weeks at work and at home. I spent a lot of time working with some members of the IBM SAP consulting practice on enterprise integration issues related to connecting SAP to non-SAP systems. It was fun and I learned a little about the “order to cash” process while I was at it but it suffocated my blogging-related brain cells. I also spent numerous weekend hours braving the June and July heat in Nashville to scratch a couple of items off my “honey do list.” These items were however only belatedly off the list as I was reminded “if you’d done it earlier in the year it wouldn’t have been so hot.” Also during this time I have been trying to take better care of myself and get some much needed exercize on weeknights. Put those three things together and you have very few discretionary hours left for blogging. Surely, I am not the only blogger to have this problem?