Columns

ABT Corp.'s Christopher Murray

In 1981, New York City-based ABT Corp. President and CEO Christopher Murray took his experience in big financial IT shops and parlayed it into a prominent position in the world of project management software. Murray recently spoke with Managing Editor Jack Vaughan in ADT's offices. The topics of discussion included the company's ABT Repository 3.0 and new Resource Manager products, and soon turned to the programmer shortage, "packaged" software projects, and the past and future tense as seen by IT.

Q. So many of today's challenges are in the project management realm, yet the project manager's view can be narrow.

A. It's sort of the case that you work in the present tense if you're a project manager, and you work in the future tense if you're an IT director or CIO. If you're an IT director or CIO, you're probably more at risk for making promises that you later can't keep and for having individual projects that later can't be managed. One of our clients is looking to save about a half-a-million dollars a year by reducing the reliance on outside contractors by having the information in one place about all of the commitments that IT has made, the plans and promises made for future delivery, and the profiles of what is going to be required in order to deliver.

I have this sign that says the future has a way of becoming the present. All of us that look into the future eventually have to face it. We've been doing some focus groups and discussions, and there is a surprising lack of confidence about the ability to efficiently staff upcoming work because of issues surrounding the current work that is going on, [and] issues surrounding the resources and what I call the business-value delivery of programs that are projected.

That's what we're seeing. I was meeting with a large IT organization overseas a few weeks back, and there was almost a fight that broke out at the table - a major disagreement about just how many people they had. They didn't know if it was 1,200 or 1,400. So it's not hard to imagine that, if you bring some rationality to that - if you get the projects defined, the resources defined and the future work defined - at least you've got a dialogue. You have a common language you can begin to work with.

Q. Is there a programmer shortage

A. Yes, absolutely. In fact I asked a leading question like that and got a little bit of a surprise answer. We were talking about putting in place these new processes and tools. I asked an IT director: 'You're going to give your project directors new tools, and give them training. You're going to expect more of them. Are you expecting some of them not to make the grade? Are you actually going to wind up having some of them replaced?' And he said, 'No, I can't. Because I can't replace them. I've got to find a way to get all of them performing at a level that allows me to continue to employ them.'

There are other interesting themes that come with this, particularly from the perspective of the in-house IT organization as opposed to the integrator. We do major business with both. What you try to help the integrators do, obviously, is to become much more sharp at being able to get projects and to manage projects. What you're doing on the other side is helping organizations deal with the problems of a large number of contractors or outside people sitting side-by-side with their in-house staff {[and]} making three times as much [money]. One of the benefits I'm hearing is that if there is better planning, foresight and management of the current work, we can shift that ratio a bit back toward in-house staff. We're going to have a lot fewer contractors sitting in the same cubicle, with the in-house folks saying 'I'd like to be over here instead.'

The other thing that people are talking about is doing a better job of effectively managing the current project work in such a way that individuals feel like there's a progressive career path for them - as opposed to them being on projects that stop, start and wind up stalled because critical resources aren't available. Suddenly, you bring in a rush of outside people and the project deteriorates - that's a work environment in which individuals become disenfranchised with their organization.

Q. What are you seeing with SAP and projects focused on off-the-shelf packages?

A. I would say the term 'packages' is a bit of a misnomer here. A typical SAP project is 10% to 15% for the package, and 85% software work that integrates and customizes it. So I think the SAP notion of a package is probably wrong; but I certainly see it everywhere and I think the expectation that these ERP products are going to be the core of the future is definitely there. But they are among the most complex projects.

Q. We see a lot of the problems coming from the approach that says 'As long we're getting off the mainframe, let's reengineer our business processes.' They bite off an awful lot.

A. Well it {{[that approach?]}} encourages you to sort of do that. And you can also talk about [SAP] as a panacea for solving the year 2000 problem - going out and starting with a package that's already compliant. That's also something of a high-risk approach, particularly now. That's because if you don't get it {{[the project?]}} done in time, there is something of a deadline out there, and most of these implementations have long tails.

But I would assert from the field we represent, that a lot of the ERP engagements that are being more effectively managed - and they are by definition enterprise-level, often affecting outside suppliers and so on - that these become just the kind of projects in which organizations find it necessary to make sizable investments in managing. And they are not individual projects that you put on either Microsoft Project or [ABT's] Project Workbench. You have them spread around. You've got people all over the enterprise working on them. You've got a tremendous need for putting it all together, reporting it, keeping people informed, and managing the outside contractors doing work with inside people. So the notion of an enterprise resource system like [SAP's] R/3 almost needs resource enterprise-level project management to work along with it.

Q. Is the year 2000 effort having a positive effect on best project management practices?

A. Very much so. Organizations know they have to be well-managed. So you find that a lot of companies come into the whole notion of program support offices. They're being driven very strongly by the willingness of management to spend whatever it takes. The other thing that makes them significant is that, at least with larger companies, there's as much involvement and concern with people outside the company as there is inside the company. We have a major relationship with Toyota. That's one of our more interesting examples about year 2000 clients. They have such an extensive supplier network that it must be in very good shape or they are very exposed. They put together an initiative endorsed by the CEO of Toyota all the way down to the IT organizations to treat this as a corporate strategic project as opposed to a 'beat up IT for getting into this fix in the first place' [project]. They are seeing it as strategic thinking. They're seeing it as a strategic benefit that could even affect their public image.

Q. The Web is changing project management as well as everything else.

A. It's become an ideal vehicle for us to implement some of the reporting, some of our results-capture, time-capture and 'statusing' activity. The new suite we're rolling out does have a very strong Web/Internet flavor to it. But it's not primarily technology-driven, it's information delivery-driven. It's also about dealing with issues, such as having a zero-maintenance client tool out there with a couple thousand team members all inputting your time. So you can go into the airport lounge and type in your status, which you can do with our toolset.

With the Internet, the theme has changed for us. The theme before was control of the work. But now it is a theme of information integration, keeping everybody on the same page, and being able to detect and put in place an early warning system so that the ripple effect can be managed. A client we were doing work with a year or so ago said his primary objective is to have a transparent organization. I like that term. It means he has a repository sitting there, the jacket's open, the data's available and he's saying to his end users 'You have complete access to everything in this repository - the status of projects, everything is open to you.' There are no more questions. If it's in there, we're doing it. If it's not in there, we're not doing it. There's no ambiguity.

Q. What are your thoughts on the Capability Maturity Model (CMM)?

A. I think the basic Capability Maturity Model is rapidly becoming almost a vocabulary - maybe too much so. The status that comes from going to Level 2 or Level 3 is such that it almost goes on people's resumes. If you look under the cover of this whole process - if you take the dominant theme going from Level 1 to Level 5 - at Level 1 you're isolated from the business, the real business. At Level 5, you are integrated with the business. You are part of the business process, in terms of value delivery and that's in a way what we were talking about. IT directors that demonstrate that they can deliver business value are the ones that basically succeed. The models, by putting in place tools that bring the users into the process, I believe are an agent for doing that.

On the question of estimating and using approaches that can give you some initial handle around the scope of projects, I think function points are marginally useful. But I think the discipline of having some standard approaches to the front-end creation of estimated work - whether it is function points or just a scaling from reengineering work that you've already done - to me, that's useful at the project level. But it may be more useful when you have to look ahead a year and [analyze] a series of activities that your users are expecting you to undertake for them. I'd like to come up with a shorter name, but I'm sort of using the notion of 'business-value delivery management,' which is a long term. But what it's saying is that if you look at your job as a CIO as being an agent for delivering business value, then that business value will usually [be put into] some kind of future timeframe.

You've got to do that or you're never going to deliver it. But you're making commitments, and I don't care what they say about the fact that you can't make commitments. Until you have a better definition, that's not the way it works. Business plans have expectations.

I believe that one of the greatest values of a methodology is in giving you a relatively abbreviated, structured way of defining what you're expecting to do in the future and a standard way of representing that. You have a method that says 'OK, I'm going to describe the work. I'm going to apply some measure of estimating to it. I will create something that we will call a placeholder for business value - call it a program, call it a portfolio - and that is what I think represents a key value. Then you can profile that against the expected requirements, cost and resources. And then you have this ability to go to your users and say 'Based on all the work going on, and where I believe these projects stand with respect to their performance and status, here is the best profile of work I can do for you.' And it's got more substance to it. When something happens that you didn't expect - a new requirement, a new business opportunity, and potentially, a slippage in the project - the question is what do I do? If you didn't have any of the stuff we're talking about, if you didn't have the projects together where you could assess them, and you didn't know what was expected of you, then how are you going to make decisions? [Things get away from] 'Who has the best scheduler?' and, as we used to say, 'Who can print the Gantt chart sideways?' and get to the important issue. And the important issue is who needs to know, and how you get that information to them.

Most   Popular