- delays in meeting project dates,
- disagreements on what the project is expected to deliver,
- difficulty solving issues,
- confusion on direction, work requirements, and status of the project,
- lack of buy-in from team members and the end users,
- additional stress and demands on the time of team members and end users, particularly near the end of the project,
- less satisfaction from the client on the final delivered product.
Many types of documents, templates, tools, and strategies exist for managing a project. This article will focus on 10 items that represent supported concepts in the project management industry and should, at minimum, be utilized for all significant application implementation projects.
Related Article: A Project Manager's Guide to User Experience
1. Solid contract with software provider
A verbal agreement won’t cut the paper it’s written on. Get it in writing! If a contract is already completed and these items have not been included, you should work with your vendor to reach agreement on these terms. Additionally, you should work with your organization to see that these items are included in future contracts.
The components that you will want to have well defined are:
1. a payment schedule,
2. outline system performance criteria,
3. penalties related to performance issues and delivery delays,
4. documentation requirements,
5. training, which is provided,
6. inclusion of a test system, and possibly a training system,
7. issue resolution/turnaround time/escalation policy,
8. and vendor support during and after the application live event.
Having these items defined contractually is an assist to the project manager. It will provide you with agreed-upon criteria allowing you the leverage to hold your vendors accountable to their deliverables.
2. Involvement by key staff and resources
The organizational structure of those involved in the project is a significant indication of the success of a project and is one of the first things you want to have in place to start the project.
Make sure to have a:
- Project Sponsor.
This person should be a senior manager head of the Steering Committee. They will be the source who authorizes the project, ultimately ‘owns’ the project, and sources the funding for the project. They would not and should not be a member of the project team.
- Leadership Committee.
This leadership committee is responsible for following the status of the project, representing the project to their peers and senior management, and assuring all of the appropriate parties are involved. This group will make any decisions that the team cannot determine, they will assist rectifying business issues and with escalation of problems including to vendors or internal staffing. Use these people! They are there for you.
- Project Team.
These are the folks that are performing the work for the project. You may have several teams, or workgroups, with different focuses.
- Project Manager.
Hey! This is probably you! The Project Manager is responsible for overseeing that the work is getting completed as expected on schedule. They manage any deviation from the scope or schedule to get the project back on track. They are generally responsible for planning and often own and complete the project documents (such as the scope, staffing plan).
Additionally, consider the following while staffing the project team:
- Be certain to include individuals who know the business. If there are different aspects of the business involved in the project, include a representative from each of these areas. These individuals will often serve the most benefit as project team members who are active in identifying processes, business needs, and performing testing and training.
- Consider a ‘superuser’ strategy. This works well where individuals are identified early on in the project to serve as business/application experts. They may be those who perform testing and training as well as first line support for end users. These users can often serve as project team members.
- A Project Staffing Plan should be completed to include the names of the individuals involved, the committee or teams that they are serving on, and the roles and responsibilities of those individuals and teams. All team members, and their managers, should approve this plan so there is agreement on the expectations.
3. Plan how the project will be managed
Create and share a Project Management Plan that will document how the project will be managed. This should be agreed upon with the resources and management.
- Document how changes will be handled, especially those that impact the scope, dates, budget, or resources.
- Document how issues will be managed and escalated.
- State how the schedule will be managed.
- Include all methods of communications that will be used for the project.
- Once you review this with the team, you will likely be the sole audience for it. Really, it’s not that entertaining and you shouldn’t expect others to be interested in it. However, you will utilize the content to guide how various aspects of the project are to be managed and you may also refer to it if a deviation occurs where you need to reference the agreed-upon terms.
4. Define and agree upon the project scope
Write a project Scope, state what is and what is not included in the project.
- Document deliverables and assumptions.
- Refer to any requirements that were gathered. If no requirements were gathered, meet with stakeholders across the board to determine their requirements so that expectations can be documented and agreed upon.
- Include Milestones, which are significant events, with their due dates. Remember that “TBD” is not a date!
- All project team members should understand the scope.
- It is important to get formal approval from the Steering Committee on the scope before the project execution phases begin.
5. Development and management of a schedule
A Schedule is the central tool to managing a project’s activities and keeping on track.
- Develop a schedule that documents the tasks that need to be done to complete all of the deliverables outlined in the scope.
- Be sure to include dependencies, but not the work associated with those dependencies, on items that are outside the scope of the project.
- Assign names and due dates to each task. Does that seem obvious? While it is probably obvious, it is not always done. Oh, “TBD” is not a person either!
- Items that risk a delay should be done as early as possible. This may include such things as ordering hardware or scheduling training.
- Highlight tasks that are milestones from the Scope. This will allow better tracking and reporting of those milestones.
- Note items that are on the critical path (these are tasks that if delayed will delay the rest of the project). Special attention should be paid to these tasks to keep the project on time.
6. Management of an Issues List
Having one central repository to log issues is invaluable.
- Each issue should include a clear description, name of who is assigned to own/resolve the issue, a due date, status, and priority. If an issue is being resolved by someone who is not on the team, it should be assigned to a team member who is responsible for tracking the issue. Another note, “ASAP” is not a date! Your ‘soon’ and someone else’s ‘soon’ can be two entirely different times!
- “High” priority should be reserved for those issues that, if not resolved, could impact the stability of the application, the integrity of the data, or completion dates of critical tasks and events.
- Track issues actively (daily or weekly). Include new ones as soon as they arise. Log updates to each issue as they become known.
- Document issues even if they are likely to be easily solved. Those tend to be the ones that get away and should not be ignored.
- Share the issues list with the entire project team; get updates regularly from the owners of the issues as well as team members who may have items to add.
7. Solid Testing
Testing is critical to understand how the application will work in the installed environment, if it performs according to expectations, and to identify any problems with the software or processes so they are addressed prior to the live event.
- Document what type of testing must be done (i.e., database conversion, data flows, user front end, business flow). Include who will be involved in testing and how it will be performed.
- Write Test Scripts that detail all scenarios that could occur. Business end users should be involved in this as they are most likely to understand all aspects of their business.
- Test items that are standard operations as well as those items that occur infrequently.
- Conduct user testing with staff members who are familiar with the business for which the application is designed. They should be validating the application for their business.
- Allow time in the schedule to retest anything that did not work initially. If any changes are made to software or setup, run through most tests again to assure there is no negative impact in other areas.
- Determine security access, setup, and test user accounts prior to live.
8. Training Program
Proper training is essential to assure that end users are prepared to use the application.
- Identify all users early on in the project; this will help to confirm all possible scenarios are covered and all users are part of the project communication.
- Training will be optimized, and sessions better received, if individuals who will have similar use of the application are trained together. Also, if there are users who are not familiar with computer systems, consider holding a general knowledge training first.
- If the possibility exists, allow the users to have access to the test or training system before the live so they can practice. Consider providing practice scenarios for this occasion.
- Create a Tip Sheet that is easy to read and highlights the top items a user would need to know. This can be useful for the live as well.
9. Preparation for Live Event
A review of all deliverables and tasks should occur weeks before the system is ready for production use.
- Anyone involved in the project should verify that all tasks are completed, or will be completed as scheduled, for the live event.
- Issues should be scrutinized at this time so a decision can be made regarding their potential impact to the live.
- Assign staff who have a good understanding of the application and business to assist users during the first days of production use. Establish a central call number that is staffed with individuals who can track, solve, or escalate issues.
Communication is one of the key items recognized as leading to a successful project. It should also be noted that in projects experiencing problems, communication is often reported as lacking. So last, but certainly not least, are tips to improve this valuable activity.
- Keep committees and teams informed. The Steering Committee should be meeting at least once a month. The agenda should include a review of an up-to-date status report and focus on any issues or concerns with dates or deliverables. This committee should not be concerned with the work outlined in the schedule, but rather the higher-level milestones. The same holds true with issues. Only review high-priority issues that may have a negative impact on the project and not the entire issues list.
- Team meetings should occur weekly or as needed. Even a short conference call meeting can be effective to get everyone together. Those involved will have an opportunity to state something that may otherwise be overlooked. Status on the work being completed can be shared with all team members to assure everyone is in line with what is expected.
- Monthly or weekly Status Reports should be completed and shared with all involved individuals. The status report should include: status of milestones, recent work completed, what work is to occur next, high-priority issues, and changes to budget, scope, schedule, or resources. This should not be a detailed account of activities but rather a summary.
- Users should be informed of the progress of the project as it evolves. Try to present them with demonstrations of the application in advance. Distributing emails or newsletters are a good way to get information out and often receives a positive response. End users do not need to know about problems, but the more they are involved with the status of the project, the more they will accept the change.
- Remember that communication is vital to the success of a project. It allows for establishing expectations and keeping everyone informed. Only provide recipients with information they require and do not burden them with excessive details. Different audiences may require different formats or content.
Consider the above items when approaching your next project. Although this article describes some instances specific to application-related projects, most strategies will be valuable to any project.
Don't forget to leave your comments below.
Brenda Hallman has over 15 years of experience in project management, most recently in the Project Management Office at Main Line Health where she is responsible for standards, tools, mentoring, education, and program development for project management staff. Ms. Hallman has a Bachelors of Science Degree in Computer Science and Mathematics from