Difference between revisions of "NewYork2008:Implementing an Existing Database Software or Service"
|Line 111:||Line 111:|
Rationale for variation
Rationale for variation
*initiate to plan phase is where most of these come up
Revision as of 23:28, 13 January 2016
There are a lot of database applications that exist, both out-of-the-box installations, and SaaS (Software as a Service) applications that organizations use over the web. How do you manage an implementation of a database product or service? How do you get get the feedback and input from important stakeholders, work with the vendor, get people trained, and make sure it all happens well before that essential year end report is due? We'll share experiences, ideas and best practices.
Michelle Murrain - facilitator:
Session: Migrating to pre-existing solution (Salesforce, eTapestry, etc.)
1/10/08 2:00 PM
Basic Issues people face in migration/mapping:
Upgrades User issues
Question (Michelle): If implementing new software/system, how do you get users on board, trained, in support of, etc?
* In some cases, users push the change in the first place * Personalized training user by user * On demand, as needed sharing
Determine Scope, is the project organization-wide or does it only affect one department? One user?
How do you prepare users for a change in complexity moving from one application to another:
Responses: Choose good software, implementing problematic software is needlessly challenging Implementation and training as close as possible to one another There's a difference between people who will use the application and people who need the information being entered. One issue in implementation is managing this difference.
Change Management - what are the main issues in moving from one software app to another:
Users unfamiliar with new application Loss of functionality of new applications, often for personal purposes (Youtube, banking, etc.) Change caused to business processes Moving paper processes to online processes involves significant "comfort" issue with users. Letting all staff/users know very clearly "why" a new application is being implemented can help with buy-in. Dealing with legacy information is a problem. Requires time/effort to either clean data or determine whether or not it's needed.
"Square peg/round hole problem" what strategies do people have for working around limitations in off-the-shelf software:
Increase backoffice workload to resolve specific problems. Suggest use period (one month, two months, etc) then report back on needs. What is the output, is this functionality actually required to accomplish the output
"If the users aren't happy they will revolt."
Biggest challenge in implementing software packages is managing impact on users. Difference with an existing package over custom built application is ability to meet specific user needs. Sales process - show benefits of software, sell, convince of utility Decision for application should NOT come from the IT department
Second set of notes (Lena's note: edit in)
Session consisted of mostly people who work for non-profits, although a few people that also work for companies that consult for non-profits and some that consult independently. There was a wide range of project management and software project management experiences in the group.
Question: Why does it seem that people are moving more towards software development projects?
- People want to use software to resolve issues but would like to leave the project management to others
- Industry is buying into software, but pre-packaged programs don't exist for that industry
Interface between project and IT departments
Feeling responsible for the growth of the whole field
Figuring out what people actually want (needs assessment)
Different types of personalities on the team
Politics interfering with the management of the project
Corporate refugees adjusting to the culture of non-profit
The many hats one project manager has to wear
Not enough systems thinking
Scope changes in the middle of the project
-How to prevent?
-How do deal?
The accidental PM
Split between techies and non-techies
Immediate demands vs. best practices
Rationale for variation
- The initiate to plan phase is where most of these come up
Collaborating with others
Solutions for dealing with non-profit culture
Some high-level technology training for the upper management
Book about Project Management, by Project Management
Additions to framework
Testing is a big part of the monitoring
Possible research between initiate plan
Things that help:
Assume that there is going to be a crisis. The test is how you handle it.
Anything is possible