|Read more about this book|
(For more resources on this subject, see here.)
The steering committee
To succeed, our Records Management program needs continued commitment from all levels of the organization. A good way to cultivate that commitment is by establishing a steering committee for the records program. From a high level, the steering committee will direct the program, set priorities for it, and assist in making decisions. The steering committee will provide the leadership to ensure that the program is adequately funded, staffed, properly prioritized with business objectives, and successfully implemented. Committee members should know the organization well and be in a position to be both able and willing to make decisions.
Once the program is implemented, the steering committee should not be dissolved; it still will play an important function. It will continue to meet and oversee the Records Management program to make sure that it is properly maintained and updated. The Records Management system is not something that can simply be turned on and forgotten.
The steering committee should meet regularly, track the progress of the implementation, keep abreast of changes in regulatory controls, and be proactive in addressing the needs of the Records Management program.
The Records Management steering committee should include executives and senior management from core business units such as Compliance, Legal, Finance, IT, Risk Management, Human Resources, and any other groups that will be affected by Records Management. Each of these groups will represent the needs and responsibilities of their respective groups. They will provide input relative to policies and procedures. The groups will work together to develop a priority-sequenced implementation plan that all can agree upon.
Creating a committee that is heavily weighted with company executives will visibly demonstrate that our company is strongly committed to the program and it ensures that we will have the right people on board when it is time to make decisions, and that will keep the program on track.
The steering committee should also include representatives from Records Management, IT, and users. Alternatively, representatives from these groups can be appointed and, if not members of the steering committee, they should report directly to the steering committee on a regular basis:
The Program Contact
The Program Contact is the chair of the steering committee. This role is typically held by someone in senior management and is often someone from the technology side of the business, such as the Director of IT. The Program Contact signs off with the final approval on technology deliverables and budget items.
The Program Sponsor
A key member of the records steering committee is the Program Sponsor or Project Champion. This role is typically held by a senior executive who will be able to represent the records initiative within the organization's executive team. The Sponsor will be able to establish the priority of the records program, relative to other organizational initiatives and be able to persuade the executive team and others in the company of the importance of the records management initiative.
Corporate Records Manager
Another key role of the steering committee is the Corporate Records Manager. This role acts as the senior champion for the records program and is responsible for defining the procedures and policies around Records Management. The person in this role will promote the rollout of and the use of the records program. They will work with each of the participating departments or groups, cultivating local champions for Records Management within each of those groups.
The Corporate Records Manager must effectively communicate with business units to explain the program to all staff members and work with the various business units to collect user feedback so that those ideas can be incorporated into the planning process. The Corporate Records Manager will try to minimize any adverse user impact or disruption.
The Project Manager typically is on the steering committee or reports directly to it. The Project Manager plans and tracks the implementation of work on the program and ensures that program milestones are met. The person in this role manages both, the details of the system setup and implementation. This Project Manager also manages the staff time spent working on the program tasks.
The Business Analyst analyzes business processes and records, and from these, creates a design and plan for the records program implementation. The Business Analyst works closely with the Corporate Records Manager to develop records procedures and provides support for the system during rollout.
The Systems Administrator leads the technical team for supporting the records application. The Systems Administrator specifies and puts into place the hardware required for the records program, the storage space, memory, and CPU capabilities. The person in this role monitors the system performance and backs up the system regularly. The Systems Administrator leads the team to apply software upgrades and to perform system troubleshooting.
The Network Administrator
The Network Administrator ensures that the network infrastructure is in place for the records program to support the appropriate bandwidth for the server and client workstations that will access the application. The Network Administrator works closely with the Systems Administrator.
The Technical Analyst
The Technical Analyst is responsible for analyzing the configuration of the records program. The Technical Analyst needs to work closely with the Business Analyst and Corporate Records Manager. The person in this role will specify the classification and structure used for the records program File Plan. They will also specify the classes of documents stored as records in the records application and the associated metadata for those documents.
The Records Assistant
The Records Assistant assists in the configuration of the records application. Tasks that the Records Assistant will perform include data entry and creating the folder structure hierarchy of the File Plan within the records application based on the specification created by the Technical Analyst.
The Records Developer
The Records Developer is a software engineer that is assigned to support the implementation of the records program, based on requirements derived by the Business Analyst. The Records Developer may need to edit and update configuration files, often using technologies like XML. The Records Developer may also need to make customizations to the user interface of the application.
The Trainer will work with end users to ensure that they understand the system
and their responsibilities in interacting with it. The trainer typically creates training
materials and provides training seminars to users.
The Technical Support Specialist
The Technical Support Specialist provides support to users on the functioning of the Records Management application. This person is typically an advanced user and is trained to be able to provide guidance in interacting with the application. But more than just the Records Management application, the support specialist should also be well versed in and be able to assist users and answer their questions about records processes and procedures, as well as concepts like retention and disposition of documents.
The Technical Support Specialist will, very often, be faced with requests or questions that are really enhancement requests. The support specialist needs to have a good understanding of the scope of the records implementation and be able to distinguish an enhancement request from a defect or bug report. Enhancements should be collected and routed back through the Project Manager and, depending on the nature of the request or problem, possibly even to the Corporate Records Manager or the Steering Committee.
Similarly, application defects or bugs that are found should be reported back through to the Project Manager. Bug reports will be prioritized by the Project Manager, as appropriate, assigned to the Technical Developers, or reported to the Systems Integrator or to Alfresco.
The Users are the staff members who will use the Records Management application as part of their job. Users are often the key to the success or failure of a records program. Unfortunately, users are one aspect of the project that is often overlooked. Obviously, it is important that the records application be well designed and meet the objectives and requirements set out for it. But if users complain and can't accept it, then the program will be doomed to failure. Users will often be asked to make changes to processes that they have become very comfortable with. Frequent and early communication with users is a must in order to ultimately gain their acceptance and participation.
Prior to and during the implementation of the records system, users should receive status updates and explanations from the Corporate Records Manager and also from the Records Manager lead in their business unit. It is important that frequent communications be made with users to ensure their opinions and ideas are heard, and also so that they will learn to be able to most effectively use the records system.
Once the application is ready, or better yet, well before the application goes live, users should attend training sessions on proper records-handling behavior; they should experience hands-on training with the application; and they should also be instructed in how best to communicate with the Technical Support Specialist, should they ever have questions or encounter any problems.
Alfresco, Consultants, and Systems Integrators
Alfresco is the software vendor for Alfresco Records Management, but Alfresco typically does not work directly with customers. We could go at it alone, but more likely, we'll probably choose to work directly with one of Alfresco's System Integration partners or consultants in planning for and setting up our system.
Depending on the size of our organization and the available skill set within it, the Systems Integrator can take on as much or as little of the burden for helping us to get up and running with our Records Management program. Almost any of the Technical Team roles discussed in this section, like those of the Analyst and Developer, and even the role of the Project Manager, are ones that can be performed by a Systems Integrator.
A list of certified Alfresco Integrators can be found on the Alfresco site: http://www.alfresco.com/partners/search.jsp?t=si
A Systems Integrator can bring to our project an important breadth of experience that can help save time and ensure that our project will go smoothly. Alfresco Systems Integration partners know their stuff. They are required to be certified in Alfresco technology and they have worked with Alfresco extensively. They are familiar with best practices and have picked up numerous implementation tips and tricks having worked on similar projects with other clients.
|Read more about this book|
(For more resources on this subject, see here.)
Good project management is central for the Records Management project to be a success. A Project Manager for the project should be selected and the manager and steering committee should agree on a suitable methodology to use for running the project. One popular and well-regarded project management methodology is PMBOK (Project Management Body of Knowledge). In the next section, we summarize PMBOK and then also look at some useful project management lessons that we can learn from the Agile methodology.
The five phases of PMBOK
PMBOK is an internationally recognized general standard that is often applied to a wide range of project types. Following a project planning methodology like PMBOK can help ensure that projects will be completed on time, within budget, and with high quality:
More information can be found on PMBOK from the Project Management Institute. This institute publishes the Guide to the Project Management Body of Knowledge (PMBOK®Guide): http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00101095501
The PMBOK methodology defines the management of a project by breaking the effort down into phases, all of which the Project Manager takes responsibility for. The methodology is quite rigorous and much has been written about the process. Only a summary of the five phases is given here:
Initiate: In this phase, the project charter and the preliminary scope statement are created. The charter is considered to be a deliverable and is a document that authorizes the start of the project. It is usually quite short, often only a single page. The project charter summarizes the objectives of the project and it names the Project Manager.
The preliminary scope statement is another deliverable document in this phase of the project. It defines what is considered to be in scope and out of scope for the project. It consists of a concise list of all work items for the project. The scope statement also includes a definition for the change control process, including how change requests will be reported, logged, monitored, analyzed, estimated, and approved.
Plan: In this phase, the project plan is created. The project plan describes how the project will be executed, monitored, and controlled. The plan includes clearly defined roles, responsibilities, processes, and tasks. It includes a description of the project, the project goals, the budget, the schedule, the resources that will work on the project, the overall approach, and a risk assessment.
The project plan needs to break down the schedule into milestones that correspond to significant accomplishments, usually the completions of a series of related tasks. The project plan describes how frequently the schedule will be updated and how schedule slips will be addressed. The plan also needs to include a list of internal and external dependencies for tasks in the schedule.
The project plan describes how costs will be managed. Cost estimate summaries are included in the plan along with a list of known factors that might cause costs to deviate from the estimates. The Project Manager needs to carefully and proactively monitor costs throughout the lifecycle of the project to ensure that the project can be completed within the approved budget.
Risks that are identified for the project are recorded and managed in a risk log. The risk log is typically another document that is maintained as a separate document. Included with risk log entries are an assessment of the likely occurrence of the risk, the potential impact and costs, and possible strategies for mitigating the risk.
The plan should also include the approach that will be used by the project manager to communicate results with the steering committee, corporate records manager, and technical and business teams. The communication strategy should address the frequency of communications and the format or technology used to communicate.
The project plan should be submitted and presented to the steering committee. Work should not start on the project implementation until the steering committee formally approves the plan.
Execute: In this phase, real work actually gets underway on the implementation of the Records Management application. Work is done and tracked. The deliverable here is the first working version of the Records Management application.
Control: During this phase, requests for project change are collected, prioritized, and controlled. Approved changes to the project are implemented and the work for those changes is managed.
Issues or bugs that come up are managed within an issue log. This is often maintained as a document, a spreadsheet, or a small database. The entry for each issue includes a description, priority, estimate of impact, and steps to resolve the issue.
Close: As a final phase of the project, the processes, the successes, and the disappointments that occurred during the project are all reviewed. The final deliverable for the project is a 'lessons learned' document.
Agile development methodology
In the last section, we walked through and briefly discussed the five phases of the best-practice project management PMBOK methodology. In this section, we consider another project management methodology known as Agile and we compare it with the more standard PMBOK methodology.
The similarity between PMBOK and Agile
Agile is a popular methodology used by software developers. It has a good track record for helping developers achieve high-quality and make rapid implementations. The use of Agile isn't limited to software development projects though. It's approach has often been successfully applied to standard project management. Agile methodology can also be broken down into five phases, which when compared with the five phases of PMBOK show striking similarities.
Agile methodology began in 2001 as part of the Agile Manifesto. More information can be found at http://agilemanifesto.org/.
In the next table, we will be looking at Scrum, a type of Agile. It comes from the rugby term 'scrum' that describes when team members circle the ball to bring it back into play.
The parallels between Agile and PMBOK are sometimes talked about when people are defending the Agile methodology, a relatively new approach to software development. The reasoning goes that everyone agrees that PMBOK is a trusted and well understood approach towards projects, and since Agile projects, at their core, follow the same basic five-phase pattern as PMBOK, it too has good grounding as a methodology that can produce reliably good results.
Scrum is an incremental iterative framework for project management of complex work assignments.
A sprint is a relatively brief time period during the life of the project, typically two weeks to a month, during which a single usable piece of work from the entire project is developed and delivered.
Numerous books and articles have been written about Agile, Scrum and sprint when applied to Project Management. For example, two popular books that describe getting started with Scrum for project management are "Agile Project Management with Scrum", Ken Schwaber, Microsoft Press, 2004 and "Agile Estimating and Planning", Mike Cohn, Prentice Hall, 2005.
That reasoning is probably valid. However, Agile too has been around long enough for it to have had its share of successes and to have become fairly well regarded. It's interesting to think now in the reverse direction about how Agile ideas can be applied to ideas of standard project management and how standard project management techniques could stand to improve. For example, for a Records Management implementation project, what kinds of benefits might we be able to derive if concepts from both Agile and standard project management were combined?
Benefits and philosophy of the Agile approach
Some of the benefits of the Agile approach include:
- Reduced costs
- Accelerated time to market
- Higher quality product
- Easier management of changing priorities
Agile methodology is based on the principle of breaking up a large project into much smaller ones, with each piece of the project completed in a deliberate and incremental way, until all project pieces are complete, all requirements have been either met or dropped, and an agreement is reached that the project is at an end.
The component pieces of the Agile project are generally short and of a fixed-length. They are called sprints or iterations. The length of an Agile sprint varies, but typically ranges from two weeks to a month in duration. At the start of each Agile sprint, the whole team meets to decide what the goals and tasks for that next sprint will be. Every attempt is made so that the work selected for a sprint will allow the team at the end of the iteration to have something demonstrable.
A core idea to Agile is the ability to demonstrate. Work completed on a sprint should be easily inspectable by people both inside the team and outside. This quality of inspectability or observability allows the completed work to be tested and validated. Waiting until the end of the project before we switch on the 'on switch' can often lead to disaster or the realization that not everything in the project fits together quite as neatly as we had planned. One reason that Agile is popular is because it provides early and tangible feedback for how a project is progressing. It can provide either a warning or a validation.
Agile is, in a way, self-correcting. A second core idea of Agile is that when something isn't going to plan, we adopt. Something may not be as easy as we thought or potentially needs to be approached in a different way. Maybe we need more people or more time or more thought. The planning and scheduling for each Agile sprint is based on the knowledge built-up from the previous work.
Agile methodology has a lot of positives, but it isn't utopia. One weakness that is frequently cited with Agile is that it makes it more difficult to be able to meet pre-determined project end dates, although, to be fair, this criticism isn't really unique to Agile.
One reason for this criticism is because Agile openly solicits comments by allowing people to make frequent inspections during the course of the project. Although maybe a bit blurry at the beginning, this approach gives people a vision of the end result early on, and those early peeks often lead people to rethink what they see, and that could lead to more change requests than might have occurred with standard project methodologies. But then, those changes can also lead to an end result of better design and higher quality than what we might have had without using Agile.
So what can be done when Agile has a problem in meeting a scheduled date? Let's turn back to the principles of project management. A basic principle of project management that holds for both Agile and traditional approaches is that projects have the constraints of time, cost, and scope. These three elements are often drawn as a triangle, as shown below. If we make a change to one, usually the other two are affected. So, if our date is slipping, you can meet it by adjusting the other constraints. For example, we could speed up a project by either scaling back on the scope of the delivery or adding more resources, which will probably result in a higher cost:
|Read more about this book|
(For more resources on this subject, see here.)
Applying Agile to Records Management implementations
How can the lessons of Agile be applied to a project like a Records Management implementation? Trying to duplicate some of the existing Agile frameworks for our project may not work well. But there are some important points that we can learn from Agile's successes. If we try to extract the essence of Agile to see why it succeeds, we can see these four practices:
- Decompose the project into milestones based on short-duration and well-defined, demonstrable tasks. Use an incremental or phased approach.
- Make the project open for inspection throughout its lifecycle and encourage people to test it as early and as frequently as possible.
- Welcome constructive comments, both critical and complementary.
- Be flexible and prepared to change and tune the project plan to accommodate both problem fixes and new ideas that may come up.
We saw in this article that there is a lot of preliminary work that needs to happen before we can actually begin the real work of designing, planning, and implementing the Records Management system. The information presented here is based on best practices and is important and shouldn't be rushed over before starting on the actual implementation of a Records Management system.
We covered the following concepts:
- The Preliminary Investigation and Records Survey
- How to identify Authority Documents relevant to the organization
- How to secure approval for the business plan
- Identifying the Resource Infrastructure for the Records Management plan
- Selecting a Project Management methodology that will enable success for the Records Management program
- Getting Started with the Alfresco Records Management Module[article]
- Introduction to Successful Records Management Implementation in Alfresco 3[article]
- Installing Alfresco Software Development Kit (SDK)[article]
- The Deployment Feature of Alfresco 3[article]
- Advanced Collaboration using Alfresco Share[article]