Differences in an eProject

An eProject is one that addresses web-based technology-driven change. Often web-based methods of working are also used in the way the project is managed, for example, using web-based Project Office tools.

Many observers note the dramatic differences this makes in the characteristics of a project. Other old cynics see it as just the next generation of technology, making little difference to the basics of Project Management.

The Pace of Change

Internet enthusiasts speak of "Internet years". They say time is moving much faster in the world of the Internet. You will find firmly-held beliefs that the Internet year is between three and ten times faster than a calendar year, the most commonly quoted factors being four or seven.

It is true that there has been a dramatic change in the technology available plus a corresponding change in commerce and social interaction. These new tools have arrived rapidly and been taken up enthusiastically by a significant proportion of the population. The perceived pace of change is thus very fast.

Do not confuse this pace of change with speed of development. The pace has been brought about by the volume of enthusiasm, attention and effort. Individual products have taken time and effort to produce. Often, the first version of an Internet product has been through much further refinement before achieving industrial strength.

The Time to Deliver

People expect eProjects to be much faster than conventional technology projects. There is an expectation that things can be done faster. Technology has been improving continuously since the industrial revolution - so there is some truth that today's technology leads to faster, more-efficient solutions.

The most valuable accelerator is always the existence of working software that does the job without significant new development. This trend started in the 1970s with basic packaged software such as General Ledgers and Payroll. Nowadays, you can get an entire working on-line bank or e-tailing operation.

Less convincing is the argument that original development is substantially faster. IT developers have been seeking faster techniques and ways to cut corners since the beginning of computers. This led to techniques such as prototyping, iterative development and rapid application development. Although many techniques have improved, there are still some basic facts of life to observe.

Over the years many important lessons have been learned, for example:

make sure there will be a benefit
make sure you understand what is needed
cater for every required aspect and function of the solution
put in place corresponding changes to processes and procedures
ensure the workforce is adequately trained and motivated
test everything that could go wrong
check the quality of the data
make sure the solution is operationally sound - robust, secure, fast enough, etc

In the initial race for Internet supremacy, time to market was essential. Very often, commercial pressures meant that the best business decision was to achieve an "80%" solution fast. Many early eCommerce business-to-consumer solutions looked great to the customer but involved staff re-keying data into the sales order systems or manually processing credit card transactions. Even now, relatively few eCommerce solutions are fully integrated.

Now that the marketplace is stabilising, the emphasis should be on the right level of quality. In many cases, this will mean a return to the discipline of IT development. For example, it is not possible to test a complex, multi-functional, customer-facing solution without considerable time and effort. More worryingly, it might not be possible to fix those "20%" gaps in functionality without re-designing the entire solution.

Case Study

An on-line vendor was early to market, but suffered from some shortcomings in their systems and operations. For example, they frequently showed items were in stock but after the customer completed the purchase they announced that the items were on back order. In many cases, the buyer would have made a different purchasing decision if the truth had been known.

The vendor then discovered customers' account details and credit card numbers had been stolen by hackers. This had to be communicated to the customers.

Net result - customers do not want to do business with an organisation that provides poor service, misleads them and subjects them to the threat of financial fraud.

Outreach and Impact

The Internet has led to some new forms of business but many new ways of conducting existing business. There are very few examples of a product or service that is only provided using the Internet. The best examples are ones that directly support eCommerce, for example authentication services. Most eBusiness ventures sell things or provide services that the marketplace has always found a way to buy - books, cars, food, insurance, banking etc. Likewise, internal eSolutions are usually only better ways to do something, for example knowledge sharing, communications, eHR and eFinance.

In most cases, the change has been to the accessibility of the product to the marketplace - and the accessibility of the marketplace to the vendor. For example, the public has always been able to deal in stocks and shares, but web-based services have made this service area easy to use and competitively priced.

A key differentiator for an eProject is its outreach. A conventional system such as sales order entry might have been seen by a hundred people. The web-based equivalent might be seen by a hundred million. The designer needs to be concerned about a huge variety of interests, backgrounds and capabilities. In the past we might have talked to the hundred sales entry clerks but it will be a difficult challenge to consult with the world population of Internet users. There may also be practical issues such as language, currency, taxation and local regulations.

As well as the numerical impact of an eBusiness solution, there is also the impact due to its visibility - particularly with people outside the organisation. Whereas in the past organisations often coped well with poorly designed internal systems, an eBusiness solution might be seen and experienced by a large number of potential customers, suppliers and business partners. It has to look good, do what the user wants, be easy to use, give accurate results and respond efficiently.

Logically, therefore, an eSolution merits greater degrees of design, construction and testing. Unlike conventional solutions, it is not practical to train the user population or expect them to stick with it whether or not they like it. Quality and fitness for purpose must be paramount.

New Technology

There is a vast array of new technologies in use, eg hardware, networking, portals, exchanges, software packages, development languages, tools, standards, etc. Many applications need to be multi-channel, ie there are multiple ways in which a person might communicate with the application, eg web-browser, iTV, mobile phone, wireless device, through a call centre, at a kiosk, over the counter.

The connection of business-to-business, business-to-consumer and business-to-employee requires compatibility and standards. Many initiatives are seeking to bring about seamless co-working. In some cases, competitive forces mean that vendors are competing rather than collaborating. It can be a difficult to choose which architecture and suppliers best meet the project's needs. Get it wrong, and you might be left with an obsolete solution.

New People - New Skills

New technologies require new skills, but not necessarily new people. Throughout the evolution of computing, technologies have evolved. Current staff usually prove to be the easiest to re-train. Whether you re-train, hire new people or buy in expertise, the bottom line is that you will need access to resources who are able to work with the new technologies.

As well as the technological changes, there are also new disciplines required. Maybe they are not new to the organisation, but they are often a new factor in technology projects. The impact and outreach of eSolutions requires specialists in such things as:

New Techniques and Approaches

Many eProjects adopt a non-traditional approach to systems development. It is common to see solutions built iteratively, each release being delivered in a short timescale - three months would be typical. Solutions often evolve in a "sand box" environment where the developers try out ideas until they have a good solution. There may be little evidence of requirements documentation, specifications, stages, project management discipline, integration, standards, functional testing, or user participation.

The Good

The Bad

Many organisations started using the web as a publishing and marketing tool. It would be natural to update it frequently with relatively lightweight controls.
The eBusiness imperative has been to get into and, preferably, ahead of the market. Short lead times have been vital even if completeness or quality was compromised.
Internet technology and its development tools make it possible for developers to create prototypes and pilots very rapidly. It is often easier and faster to create a working model than to create a theoretical design specification.
Inherent standards and simple linkage make it possible to build complex solutions as a collection of relatively simple components, each of which might be released independently.

In many organisations, IT departments were not allowed to interfere with the development of Internet systems (although they were expected to plug them into the technical infrastructure).
Much of the initial momentum for web-based systems came from young enthusiasts. They neither had the time nor the inclination to follow the slower traditional processes of systems development.
The counterpart to this youthful enthusiasm was its naivety. The wisdom of generations of systems developers was often not present or ignored.
Prior to 2000, there was often little pressure to manage and control costs.

The world of eSolutions has been maturing fast. Maybe there is truth in the "Internet years" concept - at four Internet years to the calendar year, the industry is now middle aged. Many organisations now realise that:

New Demands on the Project Manager

Today's challenge for the eProject Manager, is to harness the benefits of Internet development attitudes with the wisdom and discipline of conventional project management. It would be wonderful to achieve the best in both camps, but it cannot be done. The discipline required to manage a project's benefit, quality and risk will inevitably act as a brake on progress and enthusiasm.

It is important that you adopt a project management style and regime that suits the environment. For example: