Project Management

Project Management Overview

Good project management does not guarantee project success. Project success does not depend upon meeting the originally defined schedule, budget, or scope. But lack of good project management practices will condemn the project to extraordinarily higher costs, interminable delays, disappointing capabilities and even obsolescence before completion.

We share a proven approach that applies the OCIO’s project management methodology’s essential practices and work products.

If your Project Management Office has already defined a set of project management plans and work products, we can readily adapt our approach to work with yours. More important than the management plans and schedules is the need to establish practices that update and follow the plans throughout the project life cycle.

We apply the concepts of a content management repository, database management, workflow, and automated queries and reports to support the project management processes:

Project Administration Repository

For decades automated database projects have failed to use these same tools to manage the projects themselves. There is no more fitting adage than “The cobbler’s children have no shoes”; some might even hint that if the firm professes to have database automation expertise but fails to use these tools for the project’s management, then perhaps a more appropriate Grimm reference might be “the emperor wears no clothes.”

Word documents, Excel spreadsheets and even Access databases provide ways to format and even track issues and tasks, but they invariably rely upon a single person to make all the entries, generate the reports, perform the updates and corrections.   With the use of Microsoft’s SharePoint, we have overcome the limitations of desktop technologies and introduced internet enabled, multi-user, database centric, and role-based security to project administration responsibilities.

We use SharePoint across many of our major projects to support

• Document libraries
• Issue Tracking
• Risk Management
• Action Logs and To-DO Lists
• Project Schedule
• Calendar of Project activities and meetings
• Wiki and Discussion Board.

Document libraries enable organizing, storing, and versioning documents and setting different levels of access. Each major grouping of work products and deliverables can have its own document library. A user may have update writes to a document in one library but be limited to read-only or no access at all to documents in another library, based on project role.

SharePoint Lists enable rapid design of custom templates for Issue Tracking, Risk Tracking, and Action Logs. Each of these can exist separately or as views on shared data. The lists can share a single list of values assigned for web pages, functional areas, technical components, database tables, and other solution categories. This enables reporting on all risks, issues and actions related to a function or a web page; similarly a manager can generate a report that shows all assignments of risks, issues, and action items for each project person. The SharePoint lists are readily modified to add new lists of values to promote consistent entries, define user access levels, and generate reports and queries.

This includes the ability to provide project management plan on day one to support the key elements of the project management plan including communications and status reporting, issue management, risk management, quality assurance, and change control. This turnkey plan includes guidance for use of a Sharepoint-based repository for the administrative support of these plan element operations. Too often plans are prepared only to collect dust because the administrative processes for their execution is lacking. We have customized Sharepoint capabilities to provide a product called RAADIO that enables ease of use to manage entry, assignment, tracking, content management, and disposition of issues, risks, decisions, action items and other items that must be managed throughout the project life cycle.

As expected we use MS Project 2007 for preparation and management of the project schedule. The high level project schedule is provided now and will be flushed out in the first weeks of the project.

Approach to Project Management

This section explains the approach to project management.   There is a separate section entitled Approach to the System Development Life Cycle; that section explains the work products and deliverables related to analysis, design, build, and readiness preparation.   Project management addresses:

• Project Kickoff
• Project Management Plan
• Project Schedule preparation and maintenance
• Status Reporting
• Activities related to the PMP elements (maintaining Change Management, Risks, Issues, et al)

The time schedule below applies only to the work related to first-time approvals for plans and schedules. Project management actually occurs throughout the project through the preparation and evaluation of status reporting and managing processes for issues, risks, and changes. Management also addresses the quality assurance process including alignment of work in progress with expectations and review and approval of deliverables.

The project management plan is assembled including all of its constituent parts to effectively manage and oversee the effort. The schedule, a key component of the project management plan, is crafted and used to ensure that tasks, dependencies, and environment needs related to building the infrastructure are planned for and given adequate time to complete.

Alignment with OCIO’s California Project Management Methodology (CA-PMM)

We have applied the principles of the OCIO’s California Project Management Methodology and its underlying Project Management Institute’s Project Management Book of Knowledge. The application of CA-PMM and PMBOK does not require a literal one-to-one execution of every task and work product. We will prepare a customized Project Management Plan designed to support projects that involve fewer than 12,000 hours of vendor system integration tasks. The Plan includes elements for:

• Communications
• Issues Management
• Risk Management
• Quality Assurance
• Scope Management and Change Control.

We anticipate that there will be status reporting to an Executive Sponsor and an Executive Steering Committee. These reports may require the preparation of project overviews and more extensive use of graphics than normally applied to weekly status meeting. The use of graphics is not to “dummy down” information but rather to attract attention to the project’s importance, activities, choices, and value to our client.

Project Schedule Updates

The Plan also includes the initial Project Schedule and Project Organization. The Project Schedule will be maintained throughout the project using MS Project. At the very least, we update the project plan at the beginning of work on each major work product. The project schedule must be updated to recognize what has been learned in the last phase with regard to scope and complexity of functionality, technology decisions, availability of staff, and other factors. We will update the schedule on at least a monthly basis throughout the project. Each iteration of the schedule will add more detail on the tasks, dependenciesk, assignments, and level of effort for the upcoming work.

Status Reporting and Work Product Transparency

Status reporting will align to the major activities in the project schedule. We are skeptical of reports on the “percent complete” for work in progress. It is our experience that teams will take about the same amount of time to get to 80 percent complete as to complete the last twenty percent.

We mitigate the problems in accurate status reporting with our approach to transparency in viewing work in progress. Work in progress review milestones include the deliverable expectation document (DED), walkthroughs of work in progress, and then review of draft documents.

We will provide all of the deliverables specified in the Statement of Work. The phase and timeframe for each deliverable not related to project management are described in the Approach to the System Life Cycle section of this proposal. Each deliverable may include multiple work products, as described below for each phase of the system development life cycle. The work products for each deliverable will be maintained in the project’s Sharepoint repository. Ready access to the stages of work in progress for the work products will enhance transparency. This transparency enables project participants to better understand the purpose, issues, assumptions, and direction for the project.

The Plan includes a license for DWR usage of our RAADIO product that provides a Sharepoint-based repository for management of issues, risks, action items, change controls, and other items that need to be managed and track throughout the project life cycle. RAADIO enables more than one person to have the ability to enter an item (risk, issue, etc) but limit authorization for who can make assignments for analysis and update the status and disposition of an item. Query and reporting capabilities enable more effective tracking with less effort than possible with alternative approaches.

We recommend that DWR staff take responsibility for preparation of the Project Charter consistent with expectations of the OCIO in the SIMM description of project management responsibilities.

Project Administration Repository

For decades automated database projects have failed to use these same tools to manage the projects themselves. There is no more fitting adage than “The cobbler’s children have no shoes”; some might even hint that if the firm professes to have database automation expertise but fails to use these tools for the project’s management, then perhaps a more appropriate Grimm reference might be “the emperor wears no clothes.”

Word documents, Excel spreadsheets and even Access databases provide ways to format and even track issues and tasks, but they invariably rely upon a single person to make all the entries, generate the reports, perform the updates and corrections.   With the use of Microsoft’s SharePoint, we have overcome the limitations of desktop technologies and introduced internet enabled, multi-user, database centric, and role-based security to project administration responsibilities.

We use SharePoint across many of our major projects to support

• Document libraries
• Issue Tracking
• Risk Management
• Action Logs and To-DO Lists
• Project Schedule
• Calendar of Project activities and meetings
• Wiki and Discussion Board.

Document libraries enable organizing, storing, and versioning documents and setting different levels of access. Each major grouping of work products and deliverables can have its own document library. A user may have update writes to a document in one library but be limited to read-only or no access at all to documents in another library, based on project role.

SharePoint Lists enable rapid design of custom templates for Issue Tracking, Risk Tracking, and Action Logs. We have built a set of custom web parts that enable separate views of items that are tracked throughout a project including:

• Issues
• Risks
• Action Items and Decisions
• Questions and Assumptions; and
• Change Controls

The wide range of item types listed above can share a single list of values assigned for web pages, functional areas, technical components, database tables, and other solution categories. This enables reporting on all risks, issues and actions related to a function or a web page; similarly a manager can generate a report that shows all assignments of risks, issues, and action items for each project person. The SharePoint lists are readily modified to add new lists of values to promote consistent entries, define user access levels, and generate reports and queries.

Build Plan

The Build Plan represents a major enhancement to the project schedule. The duration, staffing, and level of effort (hours) required are pretty well known at the beginning of the Analysis phase (business analysis and functional specification).   It is even possible to estimate the level of effort for the technical architecture within about 10-20 percent. However, it is difficult to estimate the distribution of work for the detailed design and build. The Build Plan will be provided in two steps. First, the major components identified in the architecture will be used to provide high level estimates of hours and skills. Midway through detailed design we should be able to update the Build Plan with more precise tasks, assignments, dependencies, level of effort and duration for all components in the solution.