Home
About Us
Site Map
Products
Services
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Links
Contact Us
BLOG

 

 

This page is devoted to news, tips, and any other information the Project Management community may find useful or interesting.

e-Health Update

e-Health Update, November 3, 2010

Greg Reed is making progress as the new leader of e-Health Ontario according to an article appearing in Wednesday's Toronto Star. The article, written by the Star's Queen's Park Bureau reporter Tanya Talaga, reports that nearly 5,000,000 patients across the province have had their files converted to electronic form and that 5,500 doctors can now manage their patients' health files electronically. These numbers represent a jump of more than 80 per cent over the previous year.

Health Minister Deb Matthews was reported to be happy with this result. She told the Star that e-Health has "turned the ship around and progress is being made". The story also reported the dismal background for the story, quoting the exorbitant charges by consultants and consultants expensing $1.65 cups of tea. The Progressive Conservative spokesperson, Christine Elliott, was not so flattering in her comments. She criticized the progress as being "light years" behind the rest of the country. The NDP were slightly less critical, but only slightly. Their spokesperson, France Gelinas, described the news as a step in the right direction, but only a small step.

Some other details, reported in the same story: doctors have been given $28K (all figures are in Canadian dollars) over 3 years to upgrade their office systems. They must use this money to purchase software from one of 12 different vendors. Once the systems and software has been implemented, the doctors are able to communicate patient records electronically. One of the immediate benefits of this connectivity is the ability to check drug interactions on-line. Doctors no longer have to rely on their own records or their patients' memories to determine if they can safely prescribe a drug without having the patient suffer a bad reaction because of 2 incompatible drugs. Given the increase in our consumption of drugs over the last 50 years, this is no small benefit.

First a word about the e-Health programme. I've described the programme as a giant data warehousing effort in previous articles and still hold that view. The scope of the programme can be gauged by the number of patients it must support. It has absorbed 5,000,000 patients to date and will probably have to absorb another 5,000,000. Given that each patient will probably own multiple medical records, the system will likely have to store billions of records. Assuming that the figure of 5,500 doctors represents half the population (5,000,000 patients represents a little under half the population of Ontario), there will be another 5,500 doctors offices to convert.

I think it's time to congratulate Greg and his team(s) on their progress to date, not forgetting that the work done previous to Greg's arrival is of value as well. The reaction of the opposition parties is to be expected. After all, their job is to criticize the party in power. The programme's sponsor is still the government in power, specifically, Deb Matthews the current Health Minister, and a programme or project manager should manage work so that that person's expectations are met. Then it is up to the sponsor to champion the programme with the other stakeholders. Deb seems to be stepping up to the plate very nicely as the programme champion. I can only hope that Deb and Greg are making an effort to communicate this good news to the rest of the e-Health team who must be somewhat demoralized at this point.

This is the first time I have seen specifics of the programme's requirements, I'm referring to the fact that doctors are being given a choice of 12 software packages that are compatible with the e-Health system. I can only imagine the complexity that the requirement that 12 software packages must be supported places on this programme. Getting approximately 11,000 doctors to standardize data (shared data must be standardized before it can be store in a central location) will be difficult enough. Having to support 12 different applications which will have different ways of communicating the data at different times will mean that the central warehouse must determine which application it is communicating with and then modify its data transfer process accordingly.

The cost of upgrading the doctors' systems alone will amount to over $300M! This does not take into account the cost of the networks and software necessary to support all 12 applications. The story makes no mention of the affect the differing applications has on the work on the government end. The data warehouse requires an application programming interface (API) to communicate with the doctors' office systems and the API must be able to manage communications with each of the 12 different applications, or the programme must develop 12 different APIs! I don't have access to the initial requirements defined for the programme so I can't say whether this is scope creep or not, but I suspect it is a much more expensive approach than choosing a single application.

The leadership at e-Health seems to be doing many of the right things, starting with a "strategy statement" (Ontario's eHealth Strategy 2009-2012). The strategy statement does an excellent job of defining the goals and objectives of the programme. The strategy statement goes further than most project charters or vision statements and includes key milestones, critical resources, and key risks to the programme.

The goals and objectives mentioned in this document are divided into 2 groups: clinical priorities and functional priorities. The functional priorities are the IT systems, including data warehouse, data standardization, and data marts that comprise any data warehousing project. The clinical priorities include medication management, diabetes management, and wait times. I can see that medication management and the e-Health system components are directly connected. Putting the system components in place and capturing drug prescription information in electronic form will deliver this objective. Diabetes management and wait times are more of a stretch. The diabetes management objective requires the programme to establish a baseline dataset. Burdening the programme with a project to capture this data seems to me to be a huge undertaking in itself. Wait times will probably be the most contentious of these objectives.

Wait times will likely be the most contentious of the clinical priorities. The objectives identified in the strategy speak to establishing the IT tools to direct patients to the care facility best able to see them in the shortest time, to measure wait times, and report on wait times. The system will not necessarily reduce wait times without service providers making a commitment to provide accurate and up-to-date information to the system and then using the reports to improve performance. Come time to assess the programme's performance you can bet most folks will measure success by wait time reductions. If wait times are reduced, the perception will be that the programme succeeded, otherwise it will have failed.

One of the challenges for any programme manager responsible for a programme this large is the translation of the grand plan into individual project plans and the breakdown of those plans into tasks, deliverables, and milestones that the project team can manage. This programme has a great head start in that the strategy document seems to do an excellent job of breaking the programme down into individual projects and setting goals and objectives for the projects. Now it's up to the individual project managers to translate these goals and objectives into deliverables and break the work down into tasks and activities.

The other challenge that e-Health leaders have is the communication of the programme's goals and objectives and the programmes progress in meeting them. The media are in the business of selling advertising, or newspapers, or both and sensational stories tend to sell newspapers. Expecting the media to issue programme progress reports is unrealistic. Expecting them to report on the stories they cover accurately is reasonable. The leaders of this programme need to get the facts to the media. The latest story in the Star does this - 5,000,000 patients and 5,500 doctors are currently using the new system. The story even captures a measure of progress - an 80% increase in 1 year, but it doesn't tell us if the programme is on schedule or not. Getting the paper to report this simple fact would go a long way to lending credibility to the programme. It would be nice to read, listen to, or watch, a news article which tells me whether the conversion of doctors is on schedule or not, or whether it was delivered on budget or not.

The programme faces other challenges as evidenced by the requirement to support applications from 12 different vendors. There is a rule of thumb in software development projects: complexity increases effort exponentially and effort affects both cost and schedule. Burdening the programme with goals and objectives not directly connected with the conversion of medical records will also add time and cost to the programme. In previous pieces about Ontario's e-Health programme I have mentioned that changes to the programme will be inevitable because of changes in technology, changes in government, or changes to medicine to name but a few. Add to this list of external influences changes in the economy. The downturn in the economy may mean that the scope of the project will have to be reduced so that the core goals and objectives are delivered but some of the goals and objectives which are further removed from the core mission are sacrificed for a reduction in cost. It seems a shame that this option wasn't considered when contemplating the dozen software vendors the central system would have to support.

There are lessons here for the managers of less grandiose programmes and projects. The first is with regard to project scope. We all have the tendency to set high expectations for high profile IT projects. We struggle to get our projects noticed and when we succeed, have to struggle to avoid extraneous requirements that spring from stakeholders high expectations. The requirements come from business problems or opportunities that our stakeholders expect the project to address. Programme and project managers must act as a brake on these expectations. Even when the sponsoring organization is willing to provide the budget to meet all these expectations, lumping them all together into one project will cause the scope to become unmanageable. Disconnect any requirements that do not have a proximity to the project's key goals and objectives. They can either stand on their own, if they have an adequate business case to support them, or should not be part of any project. Those that enjoy some proximity can be tracked for a future project. Capturing them in a requirements register, log, or issue tracking tool will satisfy the stakeholder that their requirements are not being ignored. They can be the base of the next project, if the sponsoring organization still has the appetite to fund it.

Projects that deliver a physically tangible benefit such as a bridge, a tunnel, or a building, can be difficult enough to manage when they are large and take years to complete. Changing economic conditions, technology, and labour conditions can throw these projects enough curves to present a challenge to their managers. IT projects have the additional challenge of not being physically tangible so expectations can vary as greatly as stakeholder imaginations. Keeping everyone's feet on the ground is more difficult. Technology tends to be more volatile here than in construction so limiting the project window is more important. Fortunately, IT projects are much more easily broken down into smaller components. Instead of undertaking a huge project that will take 3 years to complete, break it down into 6 smaller ones which take 6 months each to complete. The difference will be that the projects at the end of the cycle will benefit from the experience gained doing the earlier ones. Requirements that have become obsolete will be easier to discard, especially if they are part of a future project, and new requirements will be easier to accommodate.

Once you have defined a manageable set of requirements for your project, keep your stakeholders focused on the key goals, objectives, deliverables, and milestones. Progress reporting to stakeholders must focus on these as well. It is OK to report on individual tasks and activities to the team but reporting on these details to a Steering Committee will only obscure your success, or lack of it, at achieving those goals and objectives the stakeholders expect. Expect changes to your requirements. It is seldom that a project comes along that won't involve some changes to scope. Stakeholders will learn more about their requirements on the road to defining and building them so it is unreasonable to expect that requirements won't change as a result. Once the scope, budget, or schedule for the project has changed for any reason, it is important that stakeholders understand how the changes will affect their goals, objectives, and milestones. Once that learning has occurred and baselines have been updated, you need to report on your progress towards the new goals and objectives.

Informing your stakeholders will take on the form of a marketing campaign. Repetition may be necessary to accomplish your education process, especially where stakeholders are not familiar with the best practices in project management. In addition to focusing your stakeholder reports on key goals, objectives, and milestones, try appending them to your e-mails. Capture them on the home page of your web site, if your project or programme is fortunate to have one. Standardize the way you communicate changes to the project's baselines and be consistent in reporting them. Draw the connection between the change and the baseline it changed. Don't let baseline changes come as a surprise to the steering committee in the first meeting after a change has been approved, communicate the change a summary of its benefits and the changed milestone, goal, or objective.

Comments
Login or Sign up to post comments.