Project Management Begins with Vendor Selection
Although often missed in a project, the vendor selection process is really the start of any project. Technical reviews, RFP’s, 3rd party licensing, hardware assessment, and competing projects should be assessed prior to committing to any contract. For assistance with this part of the project, see our Contract Management Services.
Project Planning
This is a critical and often neglected part of any project. A good project plan should include a very detailed assessment of current state workflows, hardware inventory, roles and responsibilities. During project planning, a skeleton of implementation timeframes should be outlines in a timeline. Dependent tasks should be aligned with their predecessors. Competing projects should be identified. Dates should be negotiated only after this assessment is complete.
Resource Planning
Large scale solutions are almost always going to have an impact on resources in within Information Technology, Departments, Vendors, 3rd party vendors, etc. Three very challenging areas navigating perception of roles and the reality of resources.
Preconceived perceptions of Roles. Departments often have preconceived notions of who is responsible for certain tasks. In practice though there are very few definitive lines. Also when the timelines are put up in a chart, additional resource requirements will often become evident. The more time to scoping the project and resource requirements, the smoother the project will proceed and the less time will be spent on conflict resolution.
Lack of flexibility. When performing a large scale IT project, there is often a perception that it is an IT project. Unless we are referring to an infrastructure update of the network, this is almost never true. Users that are going to be using the solutions are essential for QA, design of applications, managing vendors, etc. There are no islands in IT projects.
I still have patients to care for. This is the most common threat to a project. Unless this is a brand new facility, it is important to realize that this is an ABSOLUTELY APPROPIATE response. There are also ways to maintain adequate staffing for the duration of a project. This is where resource planning’s value becomes critical.
Above all, clear leadership is important to ensure projects are adequately staffed with the correct
Leadership
There are generally two types of organizational leadership, Autocratic and Ground Up. Both have the merits and problems.
Autocratic leadership makes it much easier to hold team members accountable for issues. It saves time and is at times the only way to get a project live with a strict and shortened timeline. In this model, everyone should know their roles and be prepared to assume new roles without delay and minimal complaint. However, Autocratic Leadership of a project limits creativity, resourcefulness, flexibility, and often increases cost to the project. It also tends to kill morale both on the implementation side and the end user side. However, it is useful when time is short and the project is critical. It is impossible to implement Autocratic Leadership if the leaders is not in the employees’ chain of command.
Ground Up leadership is the most effective means of large scale implementations. In this type of leadership, implementers are expected to bring ideas to the table. Ideas are evaluated and decisions are made. This improves morale among the implementers and end users as they are part of the design of the system. They also have a sense of ownership so when the system goes live, they are better equipped to answer the most common questions at go live like “who designed this?”, “Why was this set up this way?”, etc. In these instances, the answer is “the department did.” The challenge with Ground Up is that it takes more time as people get trained up. Also, it requires the leader to be very adapt to tactful handling of the team. Complaints increase because more conflict arises during the design. Managing the project becomes much more complicated. However, the payoff is well worth challenges at go live.
Implementing the Plan
A utopian vision of a project plan is that it is so good, that no revisions should ever be made. This is usual the case with smaller projects like a Reference Lab interface, or a robotics implementation. However, in my 20 years of service, I have never been on a project or managed a large scale implementation without having to adjust the plan.
Constantly monitoring risks, SWOT assessments, resource conflicts, and overall project health is critical. Leadership is important when these discussions occur. Many things that impact a large scale project have nothing to do with the plan or the assessments. Staff turnover, end of life equipment, even natural disasters will impact a projects progress. None of this can be foreseen, but they can be managed as long as the plan has be made in a flexible manner.
Accountability is important during the project life. Everyone in a project will have set backs, delays, and issues that need to be resolved. However, the team must be forthcoming with these events and communicate issues do they can be resolved. Anyone that is not forthcoming,
Problem Implementers
Problem Implementers are a few reasons that an implementer can become a problem in a project.
Many times an implementer was assigned to a project for purposes of controlling the implementation. After the project began, the implementer did not realize the quantity of work involved and quickly got distracted. If the employee is in your chain of command, that can be handled through disciplinary channels. However, if the implementer is from another department or a physician, this will be much more difficult to manage. Tact becomes critical in addressing this.
Many times implementers on a project have never been on a large scale implementation of a conversion. The inexperienced implementer will require much more coaching time. However, do not discount these implementers. Often they are departmental employees that have incredible operational experience that is needed to discover what feature of an application are needed.
The worse implementer is the one that assumes “I know more than anyone” implementer. Often they have some computer expertise, but are unfamiliar with IT implementations. Be very wary of implementers that are not communicating changes, especially if they feel that they DO NOT HAVE to communicate. They must get with the program or cut them from the project.
Training
I want to emphasize that I put training before QA of the system. Training is one of the key areas of a successful go live, but it is often put off. While you never want end user training to be too early, train to trainer classes should be done during QA. This will often require departmental resources more than IT resources. However, the only way to identify issues with the system is to get more end users involved. Good training material should be acquired from the vendor and this should be negotiated before the contract is signed. Also, training
l