Still Needs to be Solved- ⦿

This study highlights the long held concern of physicians and patient advocates that a computer in the exam room hinders the quality of care, or at least in this case, patient perception and satisfaction.

 

December 1st, 2015

Facebook Releases Open Source AI Tools ⦿

Healthcare EMR, Biomed vendors will undoubtedly be looking at this.  Unfortunately so will payers.

January 17th, 2015

Meaningful Use a Success ⦿

A federally funded study finds that criteria under the electronic health records meaningful use program “fall short of achieving meaningful use in any practical sense.” Don’t believe it.

April 18th, 2014

Google Glass in Healthcare ⦿

Hands Free Healthcare Technology

October 4th, 2013

Vendor-Client Negotiation, in Real World Terms ⦿

February 12th, 2013

The Requirements Management Challenge ⦿

February 12th, 2013

Quick Intro to Scrum ⦿

Consider sending this link to stakeholders who need a fast first lesson about the Scrum Agile Method or as preparation for a lecture or presentation about Scrum or Agile. It takes only 7 minutes, but touches on all the high points. Be prepared to elaborate…

January 20th, 2013

Agile in Enterprise – Guidelines from DOD ⦿

Found while looking for cases of Agile applied to software implementations (vs development), in large, risk averse enterprises. The white paper handbook, dated 2010, describes Agile principles and methods (presented against other and traditional approaches), provides rationale, case examples and guidelines for application within DOD enterprise projects.

Quotes of note, in the context of Healthcare IT projects:

DOD acquisition projects typically follow a highly structured, top-down, step-by-step process, based on the assumption that an end state is known. Unfortunately, this is rarely the case in modern IT projects. Long development cycles and rapidly changing requirements make it difficult to properly identify the end state of an IT system at the onset of the project.

True of healthcare organizations? Check!

The Standish Group (2009) reports that over 68% of IT projects are delivered late, over budget, or do not fully address the required system functionality (Johnson, 2009).

Check!

Agile methods are not ―all or nothing‖ approaches. It is appropriate to pick and choose practices from various methodologies as needed.
Agile should not be viewed as a solution solely for new development projects. It should be considered for all projects that involve software intensive systems, including but not limited to: IT systems, embedded systems, and equipment under control.
One of the keys to a successful Agile development project is that the entire team have Agile experience.

The challenge for healthcare IT. Few IT depts have any experience, being implementation centric, whereas Agile is relatively new and emerged within the software development paradigm.

IT projects are no longer organized or executed in a stove-piped fashion. The success of projects requires interactions with other program offices and projects that may follow a more traditional development model.

Definitely!

Furthermore, Gantt charts have some inherent flaws that keep them from being a useful day-to-day planning tool for Agile projects. The first flaw is that every task must be time estimated and assigned a date to be performed. When planning a year out, or even further, this is impractical…. Gantt charts are focused on dependencies. The fault in being overly concerned with dependencies is that there really isn‘t much of a need to track dependencies on a project level.

Conclusions:

Agile software development is not a “silver bullet” and these practices and methodologies must be implemented with care.
When implemented correctly, Scrum focuses on quick insertion of incremental capability that is driven by user feedback. It also creates a program management structure that is conducive to dealing with constant change.

September 30th, 2012

100 Lessons Learned for Project Managers ⦿

So many gems in this NASA post. Some of my favorites:

A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself.
A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work, and the best proof is for the manager to visit them and see first hand what they are doing.
Never make excuses; instead, present plans of actions to be taken.
Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure, but luck favors the competent, hard-working manager.
Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have been, and what the reality is. Documents are normally a static picture in time which is outdated rapidly.
Don’t be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help.
Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will.
Management principles are still the same. It is just the tools that have changed. You still should find the right people to do the work and get out of the way so they can do it.
A working meeting has about six people attending. Meetings larger than this are for information transfer.
All problems are solvable in time, so make sure you have enough schedule contingency — if you don’t, the next project manager that takes your place will.
Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss but, if you constantly have to solve someone’s problems, you are working for him.
There is no greater motivation than giving a-good person his piece of the puzzle to control but a pat on the back or an award helps.
Never assume someone knows something or has done something unless you have asked them. Even the obvious is overlooked or ignored on occasion — especially in a high-stress activity.
Bastards, gentlemen, and ladies can be project manager. Lost souls, procrastinators, and wishy-washers cannot.
A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management.
The project manager who is the smartest man on his project has done a lousy job of recruitment.

August 28th, 2012

Dangers of Ego-Depletion ⦿

Guest post on Tim Ferris’s blog by Dan Ariely

Tim: I’ve always suspected that we start each day with a limited number of decision-making points that, once depleted, leave us cognitively impaired. This is part of the reason that automating minutiae, adopting rituals, and applying creativity only where it’s most valuable (e.g. not deciding what to eat for breakfast) is so important to me.
Dan: Eventually, when we’ve said “no” to enough yummy food, drinks, potential purchases, and forced ourselves to do enough unwanted chores, we find ourselves in a state called ego-depletion, where we don’t have any more energy to make good decisions…

An important concept, and compelling. While this post is particularly pitched toward the subject of food, the implications for decision making in general, for managers and workers at all levels, is strong.

August 14th, 2012