The Successful Practice of Software Development BY Slide 2
Objectives Discover ways to quantify project impact and payback.
Learn how to better design and develop software solutions. Learn
how to manage development projects while keeping stakeholders happy
and informed. Slide 3 Presenters Mike Baeske, Software Developer
Team Leader, Ortho NorthEast Kevin Haverstock, IT Supervisor, Ortho
NorthEast Slide 4 Project Life-Cycle Spark of an Idea Project
Definition Design and Development Testing Training and
Implementation Post Implementation Analysis Slide 5 Spark of an
Idea All projects start with the idea that something can be
improved Observation and analytical skills are key Innovation
seldom happens in a vacuum End users are invaluable resources for
finding frustration points Slide 6 Project Definition Critical to
client satisfaction, speed of delivery, and overall success of a
project Needs to clearly define both what the project will do and
any exclusions The broad technical aspects should be defined,
ideally with screenshots when relevant Having a standardized form
can facilitate the process Slide 7 Slide 8 Project Justification
Some projects have no payback, such as due to government mandate
Requestor must submit reason/justification/savings Vague
specifications lead to lower payback because more analyst time is
needed to define the project Stakeholders need to have some skin in
the game or else theyll make trivial requests Sometimes users just
want to discuss things to see if something can be done Slide 9
Project Costs Hard costs vs. soft costs Estimating time the project
will take Break down project into smaller parts Dont forget
Analysis, Design, Project Management, Testing and Implementation Is
the time of others needed outside of the developers? You can always
come up with a range of hours Track the time spent and compare to
your estimate Refer to like projects for future estimates Time can
differ if junior vs. senior developers are used Opportunity cost:
what am I not doing because Im doing this project? Slide 10 Project
Return One person saving an hour a day could be more important than
five others saving a half hour each. Does the pay rate of the
person saving time matter? Will time savings result in seeing more
patients per day? Will fewer FTEs be needed or is it just feel good
savings? If hard dollars are involved, calculate: Cost=direct
project costs ROI=money saved Payback=time period needed to recoup
investment Slide 11 Prioritization Wildcards Low hanging fruit
Quick success vs. long time projects Will a project reap benefits
later by making subsequent projects quicker to deliver? Rank of
person requesting project Doing things programmatically reduces
errors Patient satisfaction due to better efficiencies Fun projects
Slide 12 Design and Development Refer to project definition and
requesting party Focus on minimizing end user steps Keep the
requestor informed Record time spent on both the overall project
and ideally each element / module Slide 13 Testing Should consist
of trialing every approach in the workflow to catch any issues The
extremes (first and last entries) tend to work well for initial
testing of software Once the developer feels the content is stable,
end users should test as well to catch odd workflows that developer
did not foresee With custom forms development, Control + Alt + M in
Centricity will start a MEL trace to troubleshoot issues, Control +
Alt + S will start a SQL trace Slide 14 Training and Implementation
Once testing has resulted in a relatively stable build, training
should start and a Go Live date should be established For smaller
projects, step by step instructions via email can be sufficient
training material Training in person tends to be the most effective
process but also the most time consuming. Training the trainers can
be an effective methodology where key personnel train others once
trained. Training videos via Microsoft Expression or Camtasia can
be a powerful tool for both initial training and as a resource
later on in the use cycle Slide 15 Training and Implementation
Ideally users should be able to trial new content before Go Live
date If possible, have trial Go Live with part of the organization
before doing organization-wide, to isolate any overlooked issues
Having onsite support on Go Live can both be effective and
reassuring to users Support personnel should be an expert on the
project that could potentially resolve training issues Escalate
real problems to the developer with priority Slide 16 Post
Implementation Analysis Upon Go Live, initial analysis should begin
on the flaws or overlooked aspects of the project / workflow Based
on the severity of the flaws and the time it takes to correct,
alterations should be prioritized Once a project is live for a 2-4
week period, analysis should commence on the overall success of the
project Are users actually utilizing the changes or did they revert
to old ways? Did the projected benefits actually come to fruition?
Slide 17 Adopting New Workflows / Systems Involving staff in the
entire process of a project can help with adopting it, where staff
can get a personal investment in its outcome When working with
physicians, finding a physician champion for the project is
critical in persuading all providers to adopt the new way Forcing
new physician hires into using the system can also be persuasive,
then legacy providers may see the benefits of the project and adopt
Slide 18 Project Completion Seldom do projects truly complete and
are not further enhanced Most of the time software solutions are
constantly evolving based on user feedback and needs Keeping a
record of the different changes, who requested them, and why can
help with subsequent requests Slide 19 Make vs. Buy Internal Pros
You are in total control Easy to go back to stakeholders for
clarification Can start, stop, add resources Much easier to provide
future enhancements Internal Cons Harder to get clear
specifications Hard to estimate the timeline Other priorities may
slow your project Much easier for scope creep Stakeholders
constantly bugging you Slide 20 Make vs. Buy External Pros Usually
easier to get clear specifications from stakeholders Vendor wont
get pulled by other projects Timeline is clearly defined and
usually met Ensures that stakeholder and company commitment is
strong Vendor expertise could be stronger than internal expertise
External Cons Lead time could be an issue You lose control Vendor
doesnt know your business like you do If its not clearly defined,
it aint happening Future enhancements co$t and can be slow to
schedule Make sure SOW states that you own the source code Project
cost Slide 21 Make vs. Buy Both Have a detailed design or SOW
Identify stakeholders Identify risks Create a plan for changes
Slide 22 Case Study: Cleaning Schedule Slide 23 Slide 24 Results
Staff never use it Return on investment was not worth the price of
hardware and development Lessons Learned Manager had a good idea,
but did not have end users involved in the process and did not
force staff to use the new system Slide 25 Case Study: ICD-10
Diagnoses forms Slide 26 Case Study: Ortho ICD-10 Diagnoses form
Slide 27 Results After hundreds hours of development, form is
expediting diagnosing and has saved time in training staff on how
to code in ICD-10 Lessons Learned Building the entire form per
coder guidelines and then showing clinical staff was a mistake.
Should have involved clinical staff earlier in the process to
reduce needed alterations. Slide 28 Case Study: Rheumatology ICD-10
Diagnoses form Slide 29 Slide 30 Results Finished product guides
staff in proper coding including additional codes functionality.
Lessons Learned Having the developer setup the filters and
groupings was inefficient and should be avoided. Clinical staff are
better suited for the task. Slide 31 Case Study: Internal Medicine
ICD-10 Diagnoses form Slide 32 Slide 33 Questions ? Mike Baeske
[email protected] Kevin Haverstock [email protected]
