Hi allengoogle-ga,
Firstly I have to say that this was quite an interesting read :)
On to your questions:
1. It's worth looking at each lesson to describe why it went against
generally accepted ideas and was still successful in this situation.
Lesson 1: Begin before you're ready
If you are developing an innovative product (such as a knowledge
management system) where there is no reference point, it would seem
that preparedness would be even more important to a successful
outcome. The fact that the level of preparedness in terms of what was
actually going to be carried out was loosely defined would tend to
cause a divergence in opinions, team conflict, and significant
back-tracking to get the project back on track.
Lesson 2: Commit to a rapid release schedule
Scheduled time and the amount of time actually "required" for projects
of this magnitude are typically a sensitive point of project planning,
especially for those involved who are not 100% resources. By enforcing
(seemingly) more demanding schedules on project members, it would
typically be very difficult to sustain buy-in unless everyone was
inherent motivated to successfully see the system through to a
successful completion. Even if commitment is obtained, the pressure to
produce would normally mean a downward fall in quality output - in
this case it seemed that the pressure actually caused a synergetic
result.
Lesson 3: Plan to dazzle your customers
Customer impressions, while important, should be taken in context of
the task at hand. It is surprising that following a "dazzle the
customer" mentality didn't lead the project into a ditch. After all,
understanding customer needs are the cornerstone of any software
development undertaking, and so typically creativity is limited by
strict requirements. Allowing the team to freely try out their own
ideas in this case seems to have worked only because they actually are
representative users who will go back to their consulting jobs and use
this product upon completion along with their 40,000 co-workers.
Lesson 4: Keep it in prototype longer than you think you should
Since the purpose of prototyping is to give the user a "sneak peek" at
the progress that has been made while allowing developers to confirm
that they are onthe right track. Rather than using it for this
purpose, the GBP team actually used repeated sessions to extract and
enhance requirements for the next release. This is an incorrect use of
prototyping in terms of classic software engineering, since it is
possible for users to have too much control and drive the project off
course. It is also well known that designing software for everybody is
designing software for nobody - the potential for infinite user
request certainly existed here.
Lesson 5: If you must train, be clever about it
Training is regarded by many as a critical element in user acceptance
of a product - ragrdless of how well it was designed and development.
It is rare that any stakeholders aware of this would attempt to use a
shortcut in this area. A huge amount of faith was placed on the
effectiveness of the program's design without any hard evidence to
back them up. By using pilot programs, users actually became more
focused on learning and this process, and the fact that this process
could be upheld using a hotline for support is impressive.
Lesson 6: Press hard on technology to deliver business value
This is usually the other way around - focus on the business value and
select the appropriate technology accordingly. It is hard to believe
that morphing functionality (and thus causing significant development
rework) is going to trigger adversity rather than conflict between
technical and strategic teams.
Lesson 7: Rely on fuzzy feedback before hard measures
From a statistical standpoint, this statement simply doesn't make
sense - conclusions cannot be made based on an insignficant or
unrepresentative data sample. The need to deliver results in a short
timeframe may have triggered the need for this change, though nothing
provided any foresight that this would be successful. It seems that
the success of this rule was just a stroke of luck.
Lesson 8: Choose speed and specificity over size and generality
The effect on different types of users that was observed was actually
not surprising - though ignoring one user group in favour of another
seems somewhat ignorant on the part of the development team. This is
especially true considering that the large majority of their users had
yet to use the program and still fell into the "casual user" or
"nonuser" group.
2. Most surprising result
The result that was the most surprising was the fact that the 'press
hard on technology to deliver business value' ideology was no
disatrous. Trying to build a process around technology is ill-advised
among essentially all information systems circles! Although the point
that front-end framework can limit functionality is valid, it is
certainly the safer alternative in comparison to a zig-zag timeline
(rather than one that progresses naturally). Not only was the risk of
this project high because of the type of system being developed, but
the development methodology was being recreated simultaneously!
3. Need for training - contradiction?
Since Arthur Andersen leadership had such a strong bias toward
training its staff, they felt that the users of this system were no
exception and training sessions would be provided. However, since the
users of the product were at different levels of experience with the
program, the team was able to gauge that the majority of current users
were able to proceed without the need for any formal training. These
users had been forced into using the product, likely as participants
in the many pilor projects undertaken using the knowledge base. For
those who had not tried to use the knowledge base, the reason that
many of them felt they needed training to use it was because of the
way they were conditioned to think about software use.
With previous applications, there had always been a rigorous emphasis
on training before use; the expectation was now that they would not be
able to use the program effectively without receiving a similar form
of training. By following a procedure where the user is placed in a
situation where they have to actually make use of the system and then
providing an ongoing coaching process so the user gets help when they
actually *need* to use the system.
I hope you find my feedback on these questions helpful - if you have
any questions about the material above please post a clarification and
I will try to respond promptly :)
Cheers!
answerguru-ga |
,
0 Comments
)