August 2004 Archives

There is a lot of discussion about improved processes these days, including everything from enterprise project management, development methodologies like ITIL and RUP, project portfolio management. A colleague complained once: "They are talking about creating a complicated, time consuming process involving spreadsheets and GANTT charts that could all be done on the back of a cocktail napkin." This reminds one of some of the discussion in the chapter called "A Culture Of Discipline" in Jim Collins' book Good To Great:

...the purpose of bureaucracy is to compensate for incompetence and lack of discipline -- a problem that largely goes away if you have the right people in the first place. Most companies build their bureaucratic rules to manage the small percentage of wrong people on the bus, which in turn drives away the right people on the bus, which then increases the percentage of wrong people on the bus, which increases the need for more bureaucracy to compensate for incompetence and lack of discipline, which further drives the right people away, and so forth. [p. 121]

When weighing whether to lean towards a greater level of process or stressing the amount of discipline and competence, Bob Lewis has some insight in his Advice Line weblog, in which he compares a "practice" versus a "process":

'In a practice, the "well defined steps" constitute more of a toolkit to be used by the practitioner; in a process the steps are more rigidly followed. In a practice, the intelligence remains almost entirely with the practitioner; designers move as much intelligence as possible into processes.

If you like, bowling is more of a process, baseball is more of a practice.

Which works better and in what circumstances? My opinion, unsupported by any research I'm aware of but richly supported by my personal experience, is that business redesign and application support (integration, development, enhancement and maintenance) are more effectively managed as practices. IT operations (networks, production control and so forth) are more effectively managed as processes.'

Sometimes within the context of higher ed administrative computing organizations, I've seen this corroborated. For example, the infrastructure folks heavily favor processes like maintaining fully resourced Microsoft Project plans, whereas, for an applications development team, I'd much rather establish a lightweight management infrastructure that has work decisions delegated to the lowest levels possible, with developers taking ownership of their project committments, using something like a sharepoint for documenting status and providing accountability.

Lewis's distinction between process and practice makes a lot of sense to me -- while an applications development team might work fine with the accountability framework described above, a group that is managing a 24x7 data center, will find that it makes a lot more sense to spend their creative energy developing replicable processes, not depending on good creative people to remember when they should make different types of backups or patch the servers.

As in most things, both distinctions are also a matter of degree -- some amount of process is almost always necessary and some greater amount is always too much. Process is not the cure for all ills: the overhead of process takes a bite out of an institutions' total available resources. The correct use of process is analagous to the correct use of models in software development -- as Martin Fowler noted: Models are not right or wrong; they are more or less useful." With responsibility for the lives of human beings hurtling through outer space at hundreds of miles an hour it's only logical that NASA's software assurance process is much more rigorous than the requirements for something like a university class enrollment system.

The Birmingham News ran this article about Doug Gillett, an editor with the University of Alabama's creative services department who had been posting "voluminous, partisan, well-informed, sometimes funny, and sometimes strident" commentary on the Internet for the past year -- "more than 800 words of commentary, pictures and links to articles on his own blog and contributed almost 700 words to the running arguments on Politics 101."

In his case, Gillett ran afoul of a state law that prohibited "state, county or city funds, property or time, for any political activities." Most companies and institutions have similar policies about Internet and facilities use.

That said, there can be great benefit to the insitution for blogs that cover work-related topics, both for public-sector and private institutions, and many blogs do this well. It's a tricky area, and the lines of demarcation between the individual and the institution are not always clear.

A large government or corporate organization will face tension between distributed, departmental needs and the needs of the central organization. This is one of the central themes explored in Peter Weill and Jeanne Ross's excellent book, IT Governance. They wrote about one approach to foster two-way communication (as well as to help get buy-in), when faced with such tension:

"Business/IT Relationship Managers Local business units and functions can find centrally coordinated mandates onerous or confusing. Business/IT relationship managers play an important role in communicating mandates and their implications and supporting the needs of business unit managers while helping them see benefits rather than inconveniences. Effective relationship managers must be true hybrids – equally comfortable discussing business issues, such as effective market segmentation, and technical issues, such as the best design of a distributed database to collect market segment information. When they succeed, relationship managers make any governance archetype more effective."

We will consider some other areas of this book in upcoming posts, as well.

This excerpt from the Technology Alignment section (a good read) of the California Performance Review discusses the impact of California's lack of project portfolio management:

According to Thom Rubel of the META Group, "The institutionalization of portfolio management responsibility can begin to build relationships across the government enterprise that effectively bring budget and finance offices and IT organizations into better understanding and consensus on strategic IT investments during fluctuating budget cycles. Creating portfolio management awareness within government can begin to build the bridge of understanding between IT and budget organizations and program agencies to more effectively and strategically invest in executive branch and legislative public-policy priorities."[36]
Despite its value to the state, there are currently no statewide policies, guidelines or evidence of adoption of best practices for technology portfolio management practices. For the most part, policy-makers are still not thinking of technology projects as a portfolio of investments for achieving a shared vision for how the state should serve the people, as pointed out by the Little Hoover Commission in 2000.[37]