How
has e-commerce changed the way you manage IT projects?
Danton:
The big change with e-commerce is the need for speed. We have
to get things out there quicker to our customers and we're
trying to be first to market with a lot of our applications. Mainframe
legacy system development cycles were six to 12 months. Here,
we're under six weeks. That's a drastic change. They
might be incremental deliverables, but we have changes on a six-week
cycle.
Russell:
We work with Fortune 1000, traditional brick-and-mortar companies.
They tended to outsource their e-commerce development, many times
bypassing the CIO entirely. The business [people], or the marketing
department, worked directly with a provider for lots of money.
And then the e-commerce applications were brought in-house, handed
to IT support. But the e-commerce development that had occurred
outside occurred in iterative six-week cycles and the business
people got used to that. Now the business people are saying, ‘Look,
we don't have to wait two years for anything.' They
are demanding that kind of speed from their traditional IT, which
is interesting, because some of these people are working on things
like the next release of SAP.
And
is that reasonable?
Russell:
The business demands it, and most CIOs I've talked to acknowledge
that. You have to be able to show your stockholders that kind
of speed as well. But, there is still resistance from project
managers saying, ‘You can't do this. You're just
going to end up with a bunch of garbage that no one is going to
be able to support.'
When
thinking about today's IT project management vs. project
management prior to e-commerce, what's the downside? Is anything
worse for you or at least more difficult?
Russell:
The challenge is to help people over the mental models. The mental
model for the customer is, ‘I asked you to do this and this
is your job - stop bothering me.' And then on the developer
side, the mentality is, ‘We can't get to the customer,
or they keep changing our mind, so we're just going to make
it up.' We've got to stop making business policy decisions
at the code level on the IT side.
We've
been trying to educate our customers - which seems so obvious
to people that aren't in IT - that the ultimate decision
about business [value] and which pieces [of a project] you'll
do first, the customer owns. The developers own the estimates.
So when the [customer] says, ‘I want this feature,'
the developers says, ‘That will take us this much time within
the six weeks, and we can only deliver two features in this time.'
The
other thing is that IT people find it hard to throw away the things
they've created. The idea that you build a prototype is tough.
And then there is the idea that the system is never done. A traditional
IT model is this waterfall methodology, you throw it over the
cube and it's gone into maintenance. Now we create maintenance
right away. You put something up real fast, and then you maintain
it. And there is not a definite line between software development
and maintenance projects.
With
an IBM mainframe, you knew you were going with IBM's next
release and the next one. You weren't going to change your
whole infrastructure very often, or maybe never. But [with Web
development], it's OK to throw out the technology and go
to something totally new next year. People who have been in IT
for a while define themselves through the technology they're
good at, so this is real threatening.
Aanerud:
A lot of things have improved, I just think that many of the people
brought in as project managers may not have project management
experience and have to learn this stuff from the beginning. It's
much more difficult to get them started.
When
thinking about today's IT project management vs. project
management prior to e-commerce, what has improved?
Danton:
Everybody is into it. Everybody is taking ownership. They all
take stake in projects and follow them through the various life
cycle and design phases. So it's easy to be of real value
to our customers.
Aanerud:
There is some new project management software based on the concept
of the project continuum - not just doing the initial project
management, going through user requirements and all that, but
extending that into the maintenance phase. There's the typical
stuff like Microsoft
Project
and [Experience In Software's] Kickstart
and [IMSI's] Turbo
Project,
KIDASA
Software's Milestones,
MAG
Softwrx's Timeless Time & Expense.
But also some new and innovative [software] like [Correlate Technologies']
Correlate,
which I use. Correlate and [Silicon Mindset's] Process
Revolution
and others allow you to break down some steps in the traditional
waterfall method that are really overwhelming for a project manager
and give you a better chance to track problems
Danton: I think that's a positive outcome of this e-commerce environment - breaking up these projects into separate components and bringing them together at the end. We'll have one vendor that we outsource the look and feel to. After we develop wire frame and screen prototypes, it'll develop final templates. Another team builds the business rules in Java. We'll also have our [database administrators] working on components for the database. At some phase, we bring all these components together, plug them in and begin our final iteration of testing.
Aanerud: The common term for this is distributed project management. There are a bunch of [distributed project management] tools. Unfortunately from a security standpoint, there isn't a whole lot of attention paid to these tools. So that is still something that has to be added in manually.
Russell: A lot of the traditional tools build one project plan - a master
schedule. You still have to have a big-picture schedule but it
needs to be incredibly flexible, any week. We have project review
cycles for adjusting the plan based on business conditions.
Which has always been true. It's just that for changes in a waterfall methodology, you had to blame somebody. Today, plans are supposed to change.
When working so quickly, how does a project
manager ensure security?
Aanerud: There is often not a lot of cognizance to security. The only way is to use security application development and test standards from the start, managing risk as you go through the rapid system development cycle.
In many cases, outsourcing service providers are doing much of the work for you. So the role of the project manager in making sure that security is consistent and that security policies, testing standards and everything are being applied, is a big job.
[IT project managers] today must have a number of new skills, especially understanding the maturity of the market, the providers and the alliances. You have to work with not only internal managers and customers, but also vendors and alliance partners, trading partners and staff. That's a big, big area of risk from a security standpoint.
Danton: At GE, we have a corporate e-security council that gives us standards and directions on application development. At the division level at GE Silicones, we also have our experts do security reviews and tests. Prior to deployment, we have a service-level agreement with the [security] department. They'll review within 24 hours and give us actions that need to be taken. So they're built into the organization, our security reviews and models, because security is one of the major, critical quality issues for our customers. They assume their data and their applications are going to be safe.
What do you give up when you're doing
security in 24 to 48 hours as opposed to six months?
Aanerud: Traditionally you did a detailed code review from a security standpoint. You put a test plan together and did it in a secure environment. Then you would go through stages of testing. Nobody can afford to do that in this environment. What I've seen being done relatively successfully is a quick risk assessment I call a factor analysis. Who's going to have access to the application? What's its purpose? What is the sensitivity of the data? You get to test the top few from a relatively high level but you've got to include security in the distributed project management.
You've got some advantages compared to the old days, too, like reusable code. If you add an application to a server, that server has already been through some kind of security test analysis. If you have intrusion-detection sensors, if you have the firewalls set up properly, you've got a base environment that is fairly secure.
Russell: If we're treating security as one of the iterative, concurrent features - which you should be doing - you're not finishing the whole thing before you start security. You're catching things earlier and operating on smaller pieces. There is a tremendous emphasis on testing each feature and then testing as a whole.
Danton: In our application design, we also build in security features. We do audits of our transactions to make sure they fall within certain tolerances. We have 24-7 alarm systems. So when events fall out of specification, a lot of good people investigate.
Aanerud: You also have to look at more than just your company. If you are a relatively immature company, say a small dot-com, chances are you're going to hire a Web host company for your servers, and you are going to rely on their expertise in putting those things together.
I have done reviews on behalf of clients that were looking at using Web-hosting services and on the behalf of the Web-hosting companies themselves. And I can tell you that their security is relatively immature. You may have shared firewalls, shared tape storage, with other companies. You may have shared back-office access through secure - or sometimes not very secure - remote-access capabilities.
GE is very mature. It has all of the policies and procedures in place. It has the personnel to do it. It's placed security into the systems development cycle, and it's pretty effective at it. But I can't say that for every organization I deal with. And even some Fortune 500 companies do not have that level of maturity yet. Most companies need an over-arching process to include security in the project management process and I haven't seen much of that.
The integration of security in the systems development life cycle with rapid application development isn't where it should be. In some instances I blame some security practitioners for this. They've taken a stodgy view. They say, 'Well, we need this amount of time to go through this.' They just aren't up to date with business requirements, drivers, and don't generally understand the compelling reason to get this stuff put out quickly.
Does project management change when your e-commerce
Web front-end taps into critical legacy systems?
Danton: Yes. I've been involved in e-commerce since 1996 working for Corporate Benefits. From Day 1, the real value we've realized is connecting our Web applications to the legacy systems. Our customers need to have real-time order status. We don't keep that on a Web server someplace. That's in the back office on the mainframes. So we build robust connections and links, and big pipes to our mainframes.
What you're doing is exposing internal data to the world, to your customers. And a lot of times that data may not be presentable. A container code that says, ‘We have a 400-lb. big board for sale' means nothing to our customers. We've got to change it to ‘55-gallon drum.' Exposing internal data to our external customers requires cleanup.
Does it create networking problems, too?
Danton: Yes. It creates another point of failure. Typically, people don't have backups for mainframes and mainframes don't run 24-7. If the mainframe is down, our applications queue up transactions, and customers don't seem to mind as long as we tell them. So if somebody wants to place an order with us during one of our mainframe outage periods - which might be a short period of time at midnight - we'll queue that transaction, tell the customer, and ask the customer to come back in an hour and see the transaction posted at that time. Because it's really difficult to build backups to your mainframe, you have to build them into the application.
Russell: Mike made an excellent point. Yes, it creates a level of complexity to connect all these things together, and it does create a point of failure. But that's what adds business value. So a lot of times you hear IT people say, ‘We can't do that because it's going to be too costly.' OK, then we're developing something that's not driven by the business, it's driven by IT.
Aanerud: Connection directly to a back-end database - how that is secured - is something that some companies in the past have not done well.
Danton: It's expensive to do the proper [network] integration to your legacy systems, but you only do it once.
Contact Signature Series Senior Editor Julie Bort at jbort@nww.com.
