How to conduct an e-project

The key difference between an e-project and a traditional one is time. Julia Vowler explains what this means for managing the...

The key difference between an e-project and a traditional one is time. Julia Vowler explains what this means for managing the e-team

Does adding the e-word to IT project management change everything? Is managing an e-business project any different from managing a traditional business project with a strong IT component?

The answer is no and yes. As with any project, from building a bridge to building a Web site, the principles of sound project management apply. Just because e-business involves Internet technology, it does not alter the ground rules.

But it does, nevertheless, throw up some new factors which the project management process needs to take into account.

For Julie Coltman, project director at Tenfold E-Business Group, the most glaring factor is nothing to do with the Internet as such but everything to do with the fact that users want their e-projects delivered yesterday. The rush to e-market is such that very short delivery time scales are the norm.

That means a speed up all the way down the line to collapse the time scale to an absolute minimum.

Rapid application development is essential when it comes to e-projects - everything has to be concentrated into the shortest possible timespan. The strategy stage is very much shrunk, says Coltman. Requirements specification should be done within six to eight weeks, no more, and the build within six to nine months. And these time scales are for large projects.

Scoping an e-project, however, should be no more difficult than scoping a traditional IT project, says Coltman. Although no project sizing methods are foolproof, those required for e-projects are not hugely different.

But what e-teams must accept, she says, is that an e-business venture must have built-in flexibility. All e-business is at the experimental stage. Companies are still discovering what works, what won't, how much e-business can be done at any stage, how much will be done later. Many e-projects are knowingly only half the job - companies are launching e-business ventures that will do for the moment. But with expansion and evolution is anticipated from the word go.

"We need to have a very fast, very flexible build," warns Coltman. "If you can't make changes you're dead in the water."

That requires an in-built ability to make decisions very fast, so it can then be implemented very fast by the project team.

"We don't mind that [our customers] make changes [to the e-project] but we do need them to make extremely fast decisions," says Coltman.

For all the primary emphasis on the impact of e-business drivers on project management, the nature of the technology in an e-project does have an impact as well.

There are two reasons for this. Most e-business ventures require a lot of different types of technology, from browsers to databases, middleware to storage and transaction monitors to security. The list of technical ingredients is substantial, which makes for complexity when it comes to bringing them all together in the course of the project.

Unproven technology

The second reason just makes the problem worse. An awful lot of the technology used in a e-business venture is new and often unproven. There are precious few reference sites and a lot of first releases - and even some pretty financially shaky suppliers which may not be around when it comes to long-term maintenance.

"E-applications have many different parts," reminds Coltman, "so you need project management that can bring lots of disparate bits together."

She advises having a project management layer she calls a technical coach who "understands the technology backwards and can coach the team members".

However, beware the temptation to use the best techie to do the hardest parts of the project. They need to work with the less experienced team members or no knowledge transfer will occur, even if time is saved.

New technology inevitably means new skills. If the products are unproven by traditional standards, so too are the practitioners. E-teams tend to have a low age profile which can itself affect the way the project should be managed. However bright and brilliant the young IT practitioners are, however good they are at Java, they still lack years of experience that older team members have. That means they will need more support and guidance through the project. They must feel confident in being able to ask for help when they need it.

"We have a rule that if they're stuck on something for more than 10 minutes they have to ask for help," says Coltman.

When it comes to doing the project, she says, expect two key differences from a traditional project. The first is that there will be much, much greater emphasis on usability. E-business exposes a company to the merciless regard of its customers, who are only a click away from your rival's site. Establishing usability plays a far greater role and will absorb far more time and effort.

It will also inevitably involve far more changes than a traditional project. The usability of the site is tried out, tried out and tried out again and again, iteratively changing to find the best design.

Project managers may well also have to accommodate the "luvvie" factor at this stage. Creative types, as all good, logically-minded techies know, come from a different planet. The project team may find itself exposed to "extremely creative marketing people who want purple flashing lights on the screen," warns Coltman.

Although, "the worst thing you can do is give in completely, you have to understand why they might want such a thing - they may have very sound reasons. You slap them down at your peril," she says.

Once again, it comes back to understanding and appreciating the business vision and strategy behind the project.

The second major difference, says Coltman, is that there will no longer be a discrete, standalone testing stage at the end of the build phase. Instead, testing has to be done continuously during build stages, throughout the project.

"Usability and testing encroach into the build phase," she warns.

"People think you're mad to do performance testing in the middle of a build because you haven't optimised anything yet. But because of the speed [of an e-project] you have to build and test, build and test. So the moment we finish building the last component, or the last transaction set, that's it and the application can go straight into production."

Finally, given the huge lack of e-experience in the IT industry, users will probably find they are turning to outsiders to run their e-projects. From the consultant's point of view, one aspect is paramount, says Coltman. "The project has to be a partnership. Openness and mutual trust are the critical success factors."

Julie Coltman will be speaking at next month's annual IT and Project Management Conference on 6-7 December at Earl's Court, London. Tel: 0118-932 6665

What differentiates e-projects?

  • Speed - a rapid application development approach is essential

  • Technology - there are lots of disparate and first release technical components

  • The age profile of the e-project team is younger than normal

  • Expect input from "creative types"

  • Expect the project to change and change again

  • Usability will have far greater prominence

  • Testing needs to be integrated with the build cycle

  • Many e-projects will be lead by outsiders.

  • Read more on IT project management