page 1 proprietary and confidential challenges and opportunities implementation survival in a dot...

Proprietary and Confidential

Challenges and OpportunitiesImplementation Survival in a Dot Com

World

Lori Mueller

marchFIRST

Chicago, IL

312-913-3213


Agenda

> What are you getting into?

> ERP related tasks

> Dot Com related tasks

> What is the same

> What has to change


Agenda

> What can go either way

> Keeping your sanity

> Making it work

> Questions / Answers / Observations


Overview

> Do you remember the good old days when implementing a system took 18 to 24 months and that was totally acceptable?

> Do you remember when cost was a key deciding factor?

> Do you remember when you felt like you really knew what you were doing?


What are you getting into?

> Keys to success in the dot com world> Creating new markets> Being first to market> Providing the best products and services> No glitches when you go live> Getting the VC money> Getting the pop on the IPO



> Time to market is key> Resources and costs are secondary> Features and functions will be deferred only if

they jeopardize the “go live” date



> Controlled and uncontrolled chaos> Change, change and change again

> By the week, day, hour> Website de jour syndrome> More reactive than proactive



> Business champions are unsure of which way to go> Want advice and options> Don’t, won’t or can’t make a decision



> Formal documentation, work plans, design documents, etc. are commonly ignored> Considered CYA if they come from a consulting

organization> It is really wanted but not to the same degree

as ERP implementations> When push comes to shove you better have

something



> Most companies don’t have a clue of what they are really getting into> It looks so easy it can’t be that difficult> Kids are creating web sites in no time, why isn’t

ours up?> Who needs a business plan -- we need a web

site!



> Most packages in the marketplace are version 1.0 (even worse - beta)> The same things that we ran into in the Eighties

is happening again> Technologies are more diverse and ever changing> There is little or no support

> Technical> Documentation> Professional services

> No proven track record



> Having the knowledge and skills to envision, design, and deploy e-Commerce solutions involves a combination of skills> Business knowledge> Technical knowledge> Ability to work under daily pressure> Handling egos and demanding customers> Letting go> Willingness to take a risk and lose


ERP related tasks

> Business requirements gathering

> Package software, hardware and tool evaluation and selection

> Project and phase plans

> Gap analysis

> Customization and data migration

> Conference room pilot


ERP related tasks

> Review and final development

> Testing (Unit, System, Stress , User Acceptance)

> Training

> Deployment

> Post deployment support


Dot Com related tasks

> Visioning Sessions

> Business workshops

> Package software, hardware and tool evaluation and selection

> Project and build plans



> Customization and personalization

> Integration and messaging

> Demonstrations

> Review and final development



> Testing (Unit, System, Browser , Performance , User Acceptance )

> Marketing and customer awareness

> Post deployment support

> Site traffic data review


What is the same

> For the most part, everything> You must understand the goals of the

organization before you purchase or build a solution

> You must plan and prioritize the tasks> You must document decisions> You must listen and think creatively> You must ensure that the end solution works


What is the same

> People do not like change

> People have opinions

> Bad business practices will not be fixed with the solution if people don’t get it

> There is never enough time

> Money will eventually run out


What has to change

> You don’t have the luxury of time> Speed to market is critical> By the time you get to market, there will be

competitors that had not been in play when you started

> Your competitors will be that much further ahead of you

> Your customers (internal and external) as well as stakeholders will become impatient


What has to change

> You need to look at things in a different light> You cannot spend months in design and then

more months in development> The waterfall approach will not fit easily

> Use an iterative and incremental process resulting in usable releases

> No more big bang


What has to change

> You will be on a roller coaster> Vendors will not be able to support you in the

manner you in which you may be accustomed> There will be a lack of skilled resources to

complete the solution> Technologies will not talk or integrate to each

other> One day it works and the next it doesn’t

> You will have a “dot com” kind of day


What has to change

> Being rigid is out - you must be able to quickly adapt your development processes> The people in charge may hove no experience

in brining organizations to the web> May act like they are leading edge but want security

of traditional methods

> Changes may occur by the week, day, hour, minute

> Decisions must be quick and direction must be clearly set


What has to change

> Technology is changing> Standards are hard to come by> Developers are often enamored with the latest

and greatest technology and not with getting the solution done

> They want to be leading edge and tend to get bored easily

> The market is tight and good resources are hard to find and retain


What has to change

> You are opening your organization to the unknown> The solution will be used by external customers

> Not easily trained (On-line help is a must)> Use hardware, software and browsers that are not

state of the art> They will do things you never expected

> If it fails the first time someone visits your site, they won’t be back


What has to change

> Security is critical> You don’t want to have all of the credit cards

for your customers stolen> New laws are in the works for handling

personal information> You never know when the “bugs will bite”


What has to change

> Your business champions must be open to change> Traditional business approaches may not work

> They may not be adaptable> They may be overlooked until it is too late

> A bad process will be exaggerated when you get to the web


What has to change

> You must get the word out> Customers will not knock your door down if

they don’t know what is behind it> Marketing of the site is critical> Content must be valuable, engaging, and fresh

> You need ways to continually bring customers and site visitors back


What has to change

> UML (Unified Modeling Language) is used for almost all design and development processes> Actor Diagrams and Scenarios> Use Cases> Activity Diagrams> Module Specifications


What has to change

> Actor diagrams are visual representations of the different actors that will use the solution> May be internal (administrators, catalog

managers, credit managers, customer service representatives, etc.)

> May be external (site visitor, registered user, customer, supplier, etc.)

> You need to understand what they do and how they will interact


What has to change

> There is a one to one relationship between use cases and each interaction the actor has with the site> Use cases define an action

> May seem disjointed as they do not define an entire process

> You can link use cases together by defining actor scenarios


What has to change

> Activity diagrams link the use case with it’s decision and integration points> Useful tool for developers but not useful for

business process owners> Same limitations as use cases


What has to change

> Module specifications contain all information necessary to code a component of the solution> Screen layout> Data element definition> Tests and considerations> Objects and Methods> Program flow


What can go either way

> You can still create functional requirements> You need to know current processes as well as

the planned processes

> You will still need to know where the gaps are in the software packages selected> Customization may be more cosmetic than

programmatic



> Data flows work well with activity diagrams> You need to know what data is available and

where it is touched

> Match requirements to use cases to determine gaps> You may need to dig deeper into the packages

to make the connection



> Compromise on documentation> Document key decisions> Create proofs of concept to aid in business

decision making> Pictures are worth a million meetings



> Make the most of meetings> Meeting minutes are important> Ensure follow-up activities are monitored> Report progress> Try to get a decision on the topic during the

meeting> Be prepared to have all decisions changed and

reversed a number of times



> You need to show progress> Demonstrate the solution on a regular basis> Making cosmetic changes quickly can cover up

delays in back-end programming> Bring issues to the forefront and get a decision

> The packages just may not work the way they were sold



> Test, test and test again> Formal testing should be done but with a

different focus> Browsers> Breaking security> Content> User experience

> Find ways to reduce time between test periods


Keeping your sanity

> Be open to the challenge> Know when to stand your ground and when to

let go> Traditional development methodologies will

hold you back


Keeping your sanity

> Start with basic functionality and let it grow> Evolve the solution and entice customers and

visitors back with each rollout> Don’t try to automate all processes

> You can do manual processes in the beginning as there may be less traffic and demand on your site


Keeping your sanity

> Celebrate wins and acknowledge setbacks> Recognize that a setback may result in a better

solution> Morale will rise and fall as the project

progresses> Find ways to keep your team engaged and involved> Listen to issues


Keeping your sanity

> Things will change

> Focus on quality of deliverables

> Don’t take changes as personal> Things will continually change so take it in

stride


Making it work

> Learn from your team> Dot Com development has a natural process

> Similar to any solution development - just done in less time with less answers

> Learn from your competitors> Read the trade journals to see what is

happening (Business 2.0, Fast Company, Red Herring)


Making it work

> Beware of packaged solutions> Get references and check them out

> Recheck with those references midway through your project to see if they are still using the product

> Review documentation before making the purchase

> Only believe half of what you see in the demo and question the other half

> There are good ones available - make sure you know what you are getting


Making it work

> Take the challenge and enjoy the ride> You will learn a lot> You will see a lot> You will be more valuable to yourself, your

company, and in the market place


Questions / Answers / Observations

page 1 proprietary and confidential challenges and opportunities implementation survival in a dot...

Documents