Robert Perrine
Release 2.3
October 2007
Most of the descriptions of Project Management Office styles go back to an article released by Gartner group several years ago. I have not been able to locate a copy of that article, but Kendall, Foote and others reference it and explain the concepts.
Project Repository
- A central office for collecting metrics and preparing reports.
- Good visibility to executive management since this group prepares the reports for those executives. No particular need to spend time with the project managers as long as the status reports show up.
- This structure is likely to be isolated and have little leverage with the project managers.
Coaching
- A center of excellence.
- Focused on supporting the project managers.
- Little visibility to executive management, and thus an easy target in budget cuts.
- Training is appreciated, but will it be put to use?
- Difficult to prove that this team actually makes a difference unless you talk to the people they touched.
Enterprise PMO
- The typical model most people think of
- Central organization that desires to collect all project managers into one team
Organizations often hide their project managers to avoid loosing them to this group
Often viewed as self-serving
- An excellent model for coordinating corporate resources across multiple projects
But subject to human limitations in ability to coordinate hundreds or thousands of projects
- Good visibility with executive management so funding is achievable
- No dissension with the project managers since they all work for the PMO.
- But, very easy to loose focus on what the business needs to accomplish.
- In my experience, the E-PMO tends towards bureaucracy.
- Organizations hide their staff and hide their projects to avoid the bureaucracy.
An Alternative
Kinetics is about motion. A boulder spawns rocks. Rocks begin with jagged edges. A rock can sit on the side of a hill for decades relatively unchanged. Now roll that rock into a stream and the motion in the stream will smooth and polish the rock. The rough edges get worked out because of the motion and the inter-working of this rock with other rocks. Process improvement is like that. Start a process and let it sit on a shelf and it will have jagged edges. Put it in motion and let others interface with it and that process will be refined. Set it in motion and then withdraw. Let someone else take ownership and give them their turn at crafting the process to fit their departmental style and the corporate culture.
Ultimately the style and behavior of the PMO reflect two influences, the corporate culture and the personality of the person in charge. If the corporation wants a loose structure but needs reports, then you will get a project repository. If the corporation fears an E-PMO, then you are likely to get a weak coaching model. If the corporation hears the promises of nirvana achievable by anointing one person as the executive for all projects, then you will get an E-PMO. If the PMO staff want to sit in a closet and read reports, then the PMO will evolve into a project repository. If you like helping and teaching then you will fit best in a coaching model. If you want to be in charge, then the E-PMO allows you to do that. The personality fits the model and the model reflects the personalities of the members.
In my experience, the trick is to balance the desires of the corporation with techniques to lead the corporation to a more mature model. I call this strategy “Kinetics” to reflect motion and change. In brief, here is how I use “Kinetics”.
1. Start something small and simple. For example, introduce a simplistic template to support a new process.
2. Allow the team to adopt the template and take ownership.
3. When the template comes back to you radically modified, then the team has accepted ownership of the template and aspects of the process.
4. Continue to guide the team, but respect and nurture the transfer of ownership from you, the initiator, to the team.
5. Know when to back out of the process and let the team run on their own.
I realize that my description of “Kinetics” sounds very much like the description of a Coaching PMO. What makes the difference, however, is that my model has many facets. As Kendall and Rollins note, the PMO needs to be continually responding to the stakeholder needs. I recommend blending an E-PMO governance layer with policies and procedures that are enforced, the Coaching model by empowering the process owners and then add a layer of metrics to validate compliance.
Assessment Surveys
One of the key metrics required for effective governance is an assessment on the effectiveness and efficiency of the PMO and the processes it supports. Two key aspects of metrics are internal evaluations and benchmark comparisons with external organizations and standards. COBIT provides an excellent description of the “maturity model” for each of the thirty-eight control objectives. CMMI from SEI and OPM3 from PMI are two other maturity models. These are excellent references that allow experts to compare organizations.
|
Portfolio Management
The concept of portfolio management is “doing the right work” while operations and project management focus on “doing the work correctly”. To a large extent, Portfolio Management is “governance”. The key themes in portfolio management thus align well with the COBIT domains: 1. Plan and Organize how you will manage your portfolio starting with the surprisingly difficult activity of identifying what work is underway. 2. Acquire and Implement your portfolio reporting process and your portfolio management tools and techniques. 3. Deliver and Support the activities required to keep the portfolio updated. 4. Monitor and Evaluate all of the work in the portfolio and manage that workload by terminating activities with low yields in favor of activities that will yield more benefit. Managing the portfolio also means ensuring the right resources are working on the right activities. |
|
Based upon the model shown above and to the right, I recommend four categories: Strategy, Projects, Operations and Customer Satisfaction. The key criteria in placing the components is “accountability.” Determine whether the work is directly tied to a project, is it directly tied to a product or service (operations) or is it an overhead. Strategic overhead belongs under “Strategy” and all other overhead should either be tied to “Customer Satisfaction” or it should be eliminated.
Strategy
Management tasks and roles like Portfolio Administrator and the Information Technology Infrastructure Library Capacity Manager are “strategic”.
Other strategic components include work in support of the Intellectual Property required to run the organization such as Agreements, Policies, Procedures and Processes (defined below). Strategic work includes creating training materials, user guides etc where those materials are a one-of and not a normal “Operational” activity. For example, a periodic refresh of marketing brochures is an operational activity directly tied to a service or product. But a one time presentation to explain a new marketing approach is better classified as a strategic activity. In general, it is important to decide if the work is adding to the Intellectual Property of the company, is a one-time unique effort (project) or whether it is a repeating operation.
Projects
All projects belong in the portfolio, both big and small, regardless of what name might be used to disguise the fact it is a project.
Programs of interrelated projects are useful in grouping projects. Programs allow for a more macro-level report on progress.
Consultancy is also a type of project. By “consultancy” I mean projects in which this organization is a resource under external project management.
Operations
Daily repeatable activities need to be identified so that work can be directly tied to a product or service.
Also include those special change initiatives that belong to operations, such as a Root Cause Analysis or a Service Improvement Program (defined in more detail later in this document).
Customer Satisfaction
Include all work required to support the customer excluding the work already defined elsewhere. For example, a Service Desk is an overhead operation. Depending upon the environment, collecting, assessing and distributing metrics might be an operational activity but it could also be viewed as a customer satisfaction activity. Activities directly linked to ongoing support of a specific service or product are operational activities. Indirect and overhead activities either belong under “Strategy” or “Customer Satisfaction”.
Properly defining the “Intellectual Property” documents as portfolio components is important both because of the effort required to create and administer them but also because the portfolio provides a quick way to assess coverage. The following section provides guidance on some of the key documents with an illustrative outline for each.
Agreement
In ITIL terms, this is a Service Level Agreement, an Operational Level Agreement or an Underpinning (vendor) Contract. The categorization depends upon whether you are giving or receiving the service and whether the other party is internal or external. Contracts should follow what ever corporate standard you have. Use the same standard for both internal contracts and vendor contracts as that is the language that is spoken in your organization. When you want to document the delivery of services, the ITIL framework works quite well.
- Title page.
- Revision history.
- Purpose for the document.
- Describe the service.
- Document who to contact and when and define a cycle of regular reviews (Service Level).
- Document who to contact and hours of availability for service requests and service disruptions (Service Desk).
- Document the process for requesting additional services (Service Request).
- Document the expected availability (both hours of service and percentage compliance) including credits for breaches (Availability).
- Document the exact items that are covered by this agreement (Configuration).
- Document the expected response times and any sizing limitations (Capacity).
- Document the process and timers for handling disruptions to the service (Incidents).
- Document the process and timers for resolving problems, like fixing a software bug (Problems).
- Document the process and timers for deploying updates (Release).
- Document the division of responsibility in case of a catastrophic failure (Continuity).
- Document the financial terms including options for credits or bonuses (Financial).
- Document the process and timers for changing the agreement and collateral (Change).
- Document the escalation process to use when required (Service Management).
Policy
A policy is a governance document. It defines the rules without getting into the how-to. In general, policies should have broad coverage and be few in number so that all participants know what they are and what they cover. In contrast, procedures and processes should be prolific to ensure each unique case is described in sufficient detail. In some companies it is standard practice to embed the procedure into the policy document. In general, it is better to separate the two. Policies seldom change while procedures are subject to change with changes in tools, schedules, organizational structures and numerous other factors. Keeping the policy separate from the procedure gives the policy more stability.
- Title page.
- Revision history.
- Purpose for the document.
- Describe the scope for this policy - who and what does it govern.
- Describe the governance:
List relevant metrics used to assess compliance.
How and when will compliance be reviewed, and by whom?
How and when will external audits be performed and by whom?
What enforcement is authorized for failure to comply?
- List the dependencies.
Procedures and processes used to implement this policy.
Templates required.
References to explanatory materials.
Procedures
A Procedure is a how-to document. Policies define the governance. Procedures describe how to do the work. The following diagram and table illustrate a simple business process model diagram (also known as a swim lane diagram). The structure of a Procedure is as follows:
|
- Title page.
- Revision history. - Purpose for this document. - Describe the scope for this procedure. - List the governing policies that cover this procedure. - List the dependencies. - Describe the activity required to execute this procedure. Illustrate the activity with a diagram. Describe each task on the diagram. |
|
| Label | Description |
| Authority | Executive Management must grant authority to the Portfolio Administrator to define the portfolio and collect the data. |
| Define component types | The Portfolio Administrator must work with the Subject Matter Experts (SMEs) to define a list of component types. |
| Modify component types | The SMEs have specific knowledge relevant to this industry and this environment. They need to assist in defining the component types so that the result is mutually beneficial. |
| Current component types | At any point in time there must be a readily accessible list of component types available for review by all appropriate resources. |
| Identify current activities | The initial exploration to discover on-going activities and categorize those activities into component types is a collaborative effort. Do not expect to achieve 100% coverage initially but strive to get closer to 100% coverage over time. |
| Review and feedback | Executive Management needs brief overviews of the total and exception reporting on the activities that require action. |
| Reporting | The selection and packaging of this information is an iterative process with the Portfolio Administrator responding to the feedback from both Executive Management and the Subject Matter Experts. |
| Status, review and feedback | The SMEs have the best view of the real status on each activity. The SMEs also have a insight into the prioritization and scope of the activities that should be reported to Executive Management. |
Process
I separate Processes from Procedures in order to distinguish automated rules from documented rules. Procedures must be read and followed. Processes, by this definition, are work flows that are built into the systems. For example, many companies have event monitoring systems that link to a work flow. If the event occurs, the work flow may run automatically, or it may pop-up in order to get the attention of an operations person. In ITIL terms, these work flows are the Incident response plans. It is important to remember that these response plans are a valuable corporate asset - part of the Intellectual Property of the company. As a key business asset, these processes should be accounted for in the portfolio. It is also important that they be regularly reviewed and updated.
Templates
Templates are those forms and worksheets that need to be filled in to get things accomplished. They are a valuable corporate asset. They should be archived to ensure they are available both for copying and for updates. They should also be accounted for in the portfolio as assets.
Tools for Operational Change
Operational activities should be directly tied to the service or product “sold” to the customer base. By definition, “operational activities” are recurring, repeatable and consistent. ITIL recognizes the need to adjust those activities both via projects and through a collection of special purpose tools. Two of the most useful ITIL tools are the “Root Cause Analysis” and the “Service Improvement Program”.
Root Cause Analysis
A Root Cause Analysis (RCA) is authorization to apply resources to find and resolve the underlying cause of a Problem. It fits into the ITIL framework and is an operational improvement effort. In effect, it is a small project but might fit better in the PMI (Project Management Institute) framework when viewed as a feasibility study. The goal for an RCA is to find the underlying error and identify how to resolve the error. If the resolution is complex and time consuming, then the RCA should be closed and the effort should be packaged into a project. That project might, or might not be authorized. Thus it is important to remember that the resources committed to an RCA are only committed for a short duration and with a tightly controlled scope. A sample RCA template is outlined, below.
- Describe the symptom that has been reported.
- Document the timeline for this incident or problem. When was it first reported? Who did what? When?
- Document how the incident was resolved, by whom and when.
- Was the resolution of the incident a work around or a permanent solution?
- Document the underlying cause.
- Document the actions that have been taken or need to be taken to permanently resolve the problem with resource assignments and times.
Service Improvement Program
The ITIL framework identifies many tools. A Root Cause Analysis (RCA) is a reactive tool. It is initiated after a problem has occurred. ITIL also has multiple proactive tools. One of the tools with broad coverage is a Service Improvement Program (SIP). A SIP is, in essence, an RCA initiated before the symptom has become service impacting. Problem Management might, for example, look at the history of repeating incidents and proactively seek resolution to the underlying cause of some of the most frequently repeating incidents. A SIP is a useful format for that work. Like an RCA, a SIP is authorization to commit resources to implementing a change in operations. Like an RCA, the SIP must have a tightly controlled scope and timespan otherwise it quickly exceeds the capabilities of a SIP. Once a SIP is known to require resources in excess of some predefined number (perhaps 80-hours), the SIP should be closed and a project should be opened to do the work within a stronger framework. A sample SIP template is outlined, below. Note that my SIP template is based upon the RCA template.
- Describe the problem that requires resolution.
- Document the timeline for this problem. When was it first reported? How often is it occurring? What is the impact?
- Document the work arounds and previous attempts to resolve the problem.
- Document the underlying cause.
- Document the actions that have been taken or need to be taken to permanently resolve the problem with resource assignments and times.
Portfolio Reporting
Properly implementing Portfolio Management means that all activities are accounted for and no new activities start without authorization. Most companies find that concept difficult. While managers have learned to accept the requirements of Sarbanes-Oxley (SOX), they have not yet come to appreciate “governance”. Thus, Portfolio Management is often constrained to behave as “Portfolio Reporting”. A meaningful portfolio report should look like what the users of the report want it to look like. It must adapt to the needs of the environment and should closely resemble other reports in common use. I find a simple spreadsheet layout to be well received as most executives like being able to sort and filter the results.
Cumulative Flow Diagrams
A portfolio of projects is fairly easy to define. As you try to mix operational (repeating) activities with project (unique) activities, reporting becomes difficult. Adding a graphic, like Cumulative Flow Diagrams, allows people to quickly grasp trends. And, once the trends are made visible it is easier to justify proceeding with Portfolio Management. Ideally you want an earned-value assessment on a whole lot of unplanned activity.
The method that appears to work best for this situation is Cumulative Flow Diagrams (CFD). David Anderson has an article posted on the internet called “Using Cumulative Flow Diagrams”. David Anderson also describes this technique in his book Agile Management for Software Engineering.
Implementing CFD on a portfolio is easy. Each portfolio component has a value. For projects, the value is determined through earned value. For software development, the component values are calculated using duration estimates. For a hybrid protfolio of mixed activities, the easiest way to get a rough calculation is to give each component type a “weight”. In other words, assign an arbitrary value or duration to all of the work activities that do not have a deterministic value. Updating a policy, for example, might get a weight of 0.1 -- meaning we expect one project manager to spend 10% of one week making the update. Projects that do not yet have a fully defined scope can be reported with a weight of 0.7 -- meaning the project manager is expected to spend about 28 hours per week planning the project. This is a very simplistic approach. But it works.
An example CFD is shown below.
A CFD shows three trend lines in one graph. The first line shows the volume of work that has arrived. The second line shows the volume of work that is underway. The third trend line shows the volume of work that has been completed. In Excel this is a simple area graph based on three columns. This graph quickly tells us if work is being completed in a timely manner or if we are thrashing with lots of effort but no closure. In the illustration above, for example, the overall trend on the top line is rising at a faster rate than is the third line. This is most pronounced in the interval between weeks 15 and 23. Work was accumulating and something had to be done to address the situation. The three lines must be parallel for the system to be in balance. To correct the situation, we either needed to prune some of the backlog or get more work completed. The CFD allowed us to see the problem within two reporting cycles. It took six more weeks to bring the situation under control, but without the CFD we could have gone much longer without realizing the impending crises.
The CFD is also predictive. A single “project” will enter the system in the area representing pending work, cross the system as work in progress and exit the system when completed. Thus, the slope of the lines indicates the speed at which work is completed. With nice steep lines, the CFD for one activity might look like the diagram shown below. One activity crosses the system horizontally spending time in each of the three queues.
| Applying this technique is simple. Tally up the number of pending, working and completed activities for each type of component in the portfolio. Key those numbers into an Excel spreadsheet and multiply each by the weight assigned to that type of component. |
| ||||||||||||||||||||
| Next, sum the totals for the week, and display the results on the diagram. You see the results graphically as well as numerically. For example, the table to the right shows a steady increase in the amount of work that is pending. This requires corrective action. On the other hand, the amount of on-going work is steady. Steady is good because it is predictable and thus it can be improved. |
|
“Governance” is a very broad topic.
Governance in the USA is a cyclical theme.
Investment scandals in the 1780s led to reforms.
Scandals in the 1880s over mega-corporations and tycoons led to reforms.
And a large round of legislation followed the stock market Crash of 1929.
Sarbanes-Oxley (SOX) is the most prominent example of the current cycle of legislation.
SOX is about Corporate governance – and properly belongs to auditors.
The PMO may get involved in several ways.
Projects need to be governed and the PMO has the knowledgeable resources to do that.
Also, most PMOs tend to be linked to IT and IT needs governance.
Governance has a long history.
Consider Joseph in Egypt counting the bags of grain stockpiled for the famine.
Consider the parable in Luke 16:1-8 about a manager misappropriating his employers funds.
Governance has been around for a long time.
In the 1980s the Treadway Committee was formed in response to the savings and loans scandals.
The committee was named after the chairman, James Treadway, former heads of the SEC.
The legacy of this committee is COSO
The Committee of Sponsoring Organizations of the Treadway Commission.
A key theme in the Treadway Report is that the auditing community needs to be self-policing.
The report also emphasized the need for Separation of Duties.
The third key output was a common definition of the term “Internal Control”, now defined as:
“Internal control is a process, effected by an entity’s board of directors,
management and other personnel, designed to provide reasonable assurance
regarding the achievement of objectives in the following categories:
Effectiveness and efficiency of operations.
Reliability of financial reporting.
Compliance with applicable laws and regulations.”
But the ancestry for this latest round of regulation is credited to a UK report called the Cadbury Commission.
Accounting scandals were worldwide in the 1980s.
Investors in the UK began suing the auditing firms. The Caparo Case went to the House of Lords – the final appeal for legal matters in the UK.
The Cadbury Commission concluded that auditors are liable for best practices but not for business losses.
This report made it clear that ultimate responsibility always resides with the board of directors.
That premise was carried over to the USA in the 1990s and had implications later with Enron.
The key theme is that auditors are responsible to a professional standard, but the board of directors is responsible for the business.
Over time other organizations added their views to this discussion. Two key additions were the Basel Report and the OECD Principles.
Basel Report (Enhancing Corporate Governance in Banking Organizations) is one of the key document that outlines:
Responsibilities of the board of directors.
Reasonable expectations for shareholders and stakeholders.
Of all the reports and opinions, it appears that the OECD best represents the shareholders and stakeholders.
Their key document is the OECD Principles of Corporate Governance.
The Sarbanes-Oxley Act of 2002 continued the trends established by Treadway, et al and defined a new set of requirements for public companies in the United States. The act includes the creation of a new administrative body known as the Public Company Accounting Oversight Board (PCAOBUS). The act also includes wording changes to the 1933 and 1934 legislation for the Security Exchange Commission. Because of the impact this legislation has had on governance, I include a brief summary of the topics in this legislation with an emphasis on sections 3 and 4.
1 Public Company Accounting Oversight Board
101 Establishment; administrative provisions.
102 Registration with the Board.
103 Auditing, quality control, and independence standards and rules.
104 Inspections of registered public accounting firms.
105 Investigations and disciplinary proceedings.
106 Foreign public accounting firms.
107 Commission oversight of the Board.
108 Accounting standards.
109 Funding.
2 Auditor Independence
201 Services outside the scope of practice of auditors.
202 Pre approval requirements.
203 Audit partner rotation.
204 Auditor reports to audit committee.
205 Conforming amendments.
206 Conflicts of interest.
207 Study of mandatory rotation of registered public accounting firms.
208 Commission authority.
209 Considerations by appropriate State regulatory authorities.
3 Corporate Responsibility
301 Public Company Audit Committees
301-1 270 days after passage the SEC must ensure non-compliant companies are removed from listing on the regulated stock exchanges.
301-2 Responsibilities relating to registered public accounting firms: Every public company must have an audit committee.
301-3 Independence: Every member of the audit committee must be on the board of directors and otherwise independent from the company.
301-4 Complaints: The audit committee must provide means for receiving complaints from within and outside of the company.
301-5 Authority to engage advisors.
301-6 Funding: The company must provide the audit committee with funding for an external audit and for additional advisors as required.
302 Corporate Responsibility for Financial Reports
302-a Regulations required: The SEC shall require the principle officers of each company to sign acknowledging the following:
302-a-1 the signing officer has reviewed the report.
302-a-2 the facts are true to the best of this officer’s knowledge
302-a-3 the representations are fair.
302-a-4 internal controls have been properly designed and implemented
302-a-5 full disclosure has been made of significant deficiencies or fraud
302-a-6 disclosure is required of any significant changes made subsequent to the report
302-b Foreign reincorporations have no effect.
302-c Deadline: 30-days after this bill was signed.
303 Improper Influence on Conduct of Audits
303-a Rules to Prohibit: The SEC will create rules to prohibit fraudulent actions.
303-b Enforcement: The SEC has exclusive authority to enforce these rules.
303-c No Pre-Emption of Other Law.
303-d Deadline for Rulemaking: 90-days after passage of this bill.
304 Forfeiture of Certain Bonuses and Profits
304-a CEO and CFO will reimburse the company for bonuses, incentives, and profits from the sale of stock if there is misconduct.
304-b The SEC can make exceptions to 304-a.
305 Officer and Director Bars and Penalties
305-a Unfitness Standard
306 Insider Trades During Pension Fund Blackout Periods
307 Rules of Professional Responsibility for Attorneys
308 Fair Funds for Investors
4 Enhanced Financial Disclosures
401 Disclosures in Periodic Reports
401-a Accuracy of Financial Reports: The report must conform to auditing best practices
401-b Commission Rules on Pro Forma Figures: The commission will define additional rules going forward
402 Enhanced Conflict of Interest Provisions
402-a Prohibition on Loans to Executives: Excluding normal business loans, corporations will cease making special loans to executives.
403 Disclosures of Transactions Involving Management and Principle Stockholders
This section updates the wording in the Security Exchange Act of 1934.
404 Management Assessment of Internal Controls: Financial statements will include management endorsement of the internal controls.
405 Exemption: Registered investment companies are except from Sections 401, 402 and 404.
406 Code of Ethics for Senior Financial Officers: Adoption and updates to codes of ethics are to be reported to the Commission.
407 Disclosure of Audit Commission Financial Expert: Each Audit Committee should have at least one designated financial expert.
408 Enhanced Review of Periodic Disclosures by Issuers: The Commission shall review disclosure statement.
409 Real Time Issuer Disclosures: Prompt disclosure shall be made in “plain English” when there is a significant financial change.
5 Analyst Conflicts of Interest: This section updates the wording in the Security Exchange Act of 1934 to further define “conflicts of interest”.
6 Commission Resources and Authority: This section updates the wording in the Security Exchange Act of 1934 to create and fund the Commission.
7 Studies and Reports: The Commission is tasked to study and report on the following:
701 GAO Study and Report Regarding Consolidation of Public Accounting Firms.
702 Commission Study and Report Regarding Credit Rating Agencies.
703 Study and Report on Violators and Violations.
704 Study of Enforcement Actions.
705 Study of Investment Banks: Enron and Global Crossing are named in this section.
8 Corporate and Criminal Fraud Accountability: Amendments to existing laws to clarify and reinforce those laws.
9 White-Collar Crime Penalty Enhancements: Amendments to existing laws to clarify and reinforce those laws.
10 Corporate Tax Returns: The Chief Executive Officer of a corporation is now required to sign the federal income tax return.
11 Corporate Fraud Accountability: Amendments to existing laws to clarify and reinforce those laws.
Deployment
Based upon my involvement in four governance initiatives, I suggest the following timeline for deployment.
| Activity | Description |
| Project Charter | This is a project. It is a bootstrap project in that you need to have governance in place in order to do governance. So find out what it takes to document and authorize an initiative. My preferred tool is a PMI style Project Charter. Just remember that having signatures on the document is at least as important as any of the content inside. |
| Baseline Surveys for
Executive Management Resource Management Employees and Consultants | Document the current perception of governance by setting up separate surveys for each of these three distinct corporate layers. It is important that each layer be surveyed separately because their needs and expectations are very different. I also recommend setting up departmental surveys for the employees and consultants. This will help you identify the departments that can be used as reference locations and the departments that need special attention. Note, if you do not have permission to do all three of these surveys then you are unlikely to succeed. |
| Project Plan | Use the survey results to identify the specific focal areas that 1) need attention 2) have the potential to succeed and 3) have the potential to produce measurable results that add value. Prioritize those actions. Also, name the risks including 1) resistance to change, 2) insufficient or ineffective training, 3) insufficient or ineffective tools. |
| Project Schedule | List the activities, assign resources and durations to each and then sequence the activities. Identify progress tracking milestones. |
| Policy on Policies | Another bootstrap problem is that governance is only effective if it is consistently applied, even to governance. Thus, there needs to be a policy that defines how to approved policies, procedures and templates. And that policy needs to be approved through the process defined by that policy. This implies that the Change Advisory Board (CAB) for governance documents must be established. Note that bypassing this process for governance documents will cause the initiative to fail as the users will see it has hypocritical that they have an additional burden that the very group imposing on them avoids. |
| Document Repository | Define appropriate locations to share and secure the governance documents, training materials and collaborative materials. Shared disk space can be used but web based tools such as Microsoft Sharepoint are better. |
| Awareness Campaign | Communicate early. Communicate often. And then communicate repeatedly. All three corporate layers must be kept aware of what is happening, how it will impact them and why they should care. Awareness methods include emails, bulletin board and web site notices as well as periodic meetings. |
| Tools | Tools are required to monitor progress, assess success and failures and manage the configuration of documents. If resources cannot be located to build or buy enterprise scale tools then start with spreadsheets and tools like Microsoft Access. A simple table structure for several of these tools is included, below. |
| Training | Training is vital both to support the knowledge transfer process and as a part of the awareness effort. Corporate commitment to training implies that the hierarchy of management thinks this is important. However, it is just as important not to start the training too early as it is to avoid starting too late. Offer conceptual training early so the users know why this is important. Then offer hands-on training during a testing or pilot deployment. |
| Metrics | If they have not already been wired into the deployment, then now is the time to start collecting metrics on each aspect of this deployment. |
| Communication | Communicate early. Communicate often. And then communicate repeatedly. Time, money and resources have now been spent. Does management see value in this? Do all participants know their responsibilities? Do you know the project status and is that status being communicated to the right people in the right way? |
| Governance Documents | Once the framework is established then you are ready to begin creating, reviewing, authorizing, communicating and implementing policies, procedures and templates. |
| More Training | Now there is tangible content for the training. Train all levels of the corporation on the Governance Documents. Use each training session to communicate and raise awareness as well as transfer knowledge. |
| More Surveys | Surveys serve to both pull information and push knowledge. Properly worded questions communicate, offer training and raise awareness. |
| Internal Review | Begin compliance checks. Be gentle and then increase the intensity of the scrutiny. |
| Corrective Actions | Fix the defects identified in the internal review. Then assess whether another internal review is required before proceeding with the external review. |
| External Review | External review are required for SOX, SAS 70 and other compliance standards. |
| More Corrective Actions | Fix the defects identified in the external review. |
| Transition to Operations | Transition this work from a temporary endeavor -- a Project -- to a repeatable process -- an Operation. |
| Project Closure | Document lessons learned. Archive the project folders. Ensure the stakeholders realize value they received. |
Tools
|
Document Manifest Database (DOC)
The purpose for this database is to provide ready access to the properties for each governance document. This is actually a part of Configuration Management and this data can all be contained in a well designed Configuration Management Database. Or this information can be hosted in a proper enterprise document management system. However, if you are constrained on time or resources, you can build your own database. The data fields that I recommend is shown in the table, below, in a denormalized form. An entity diagram follows to show a possible table structure. |
|
| Field | Purpose |
| Name | The title for this document. |
| Filename | The name of the primary file for this document. |
| Category | Category or grouping for this document. For example, is this a governance document, an HR document, etc. |
| Type | Type of document -- policy, procedure, template or other types defined for your purpose. |
| Purpose | Describe the purpose for this document -- preferably by clipping text out of the heading of the document. |
| Comments | General purpose field for storing bulletin information for the users. |
| Base_Site | Name of the site, shared drive or folder holding the base document. |
| Base_Path | The path to the latest copy of this document. Use programming logic to concatenate the Document_Site, Document_Path and Document_Filename or just key in the entire link. |
| Base_Security | Who should be able to view this document as a policy, procedure or template? |
| Applied_Security | Who should be able to view this document when it has been converted from a template and applied to a use? |
| Applied_Site | Name of the site, shared drive or folder holding the applied document. |
| Version | Version of this document, or a history of the versions of this document. |
| Status | Status to go with the version. |
| Approval_Date | Date when this version was approved for use. |
| Processing_Flags | Flags are required to designate whether this document is still being worked, is ready for review, has been reviewed. This can be done through the status column or through a series of flags depending upon the complexity required for your location. |
| Responsibility | The purpose for this field is to indicate responsibilities. For example, which department is responsible for making updates. Which departments are responsible for contributing or reviewing those changes. This can be a series of flags, a set of fields or a join to a child table. |
|
Project Portfolio Database (PRJ)
The purpose for this database is to collect status information and monitor progress. Large shops can use Clarity or other systems that combine project documentation, project status and time reporting into one database. If, however, you are constrained on time or resources, you can build your own database. The data fields that I recommend are shown in the table, below, in a denormalized form. An possible entity diagram is shown to the right. The key definitions for these tables come from PMI guidelines for portfolio management. In brief: |
|
Portfolio -- a business focused grouping of programs.
Program -- a grouping of related projects worked for a common purpose.
Project -- a temporary endeavor to create a unique product or service.
Package -- the lowest level component in a work breakdown structure.
Activity -- one step lower in the decomposition of a package.
Tasks -- the work assignments.
Typically a project schedule shows tasks as the rows in the schedule. Activities are groupings of tasks and packages are the major headings within the project schedule. There are times when it is appropriate to track work at the task level. However, it is often just as effective to focus on the activity instead.
Fields in common for all four of the primary tables.
| Field | Purpose |
| Name | The name for this portfolio, program, project, package or activity. |
| Status | The status for this object. |
| Owner | The person or department responsible for this object. |
| Description | Description of the object. |
| Sequence | A field useful for putting these objects in a particular order for reports. |
| Type | Type of this object. |
|
Product Portfolio Database (PROP)
The purpose for this database is to provide the information required to set strategic direction. Many CRM-type systems can provide most of this information. Other enterprise-level software can do all of this and more. I have seen locations try to track this information via spreadsheets and it is not very workable. A small database like this is achievable for most companies, but it is just a bit complex for some. The data requirements are minor, as noted in the skeleton outlined in the following table. The complexity stems from the relationships, as shown in the figure to the right. It is the joins themselves that contain most of the information. |
|
Fields in common for all of the primary tables.
| Field | Purpose |
| Name | The name of this product, version, release, installation, or other object. |
| Status | The status for this object. |
| Owner | The person or department responsible for this object. |
| Description | Description of the object. |
| Comments | Additional space for clarifying comments about this object. |
| Type | Type of this object. |
A Few Tips on Microsoft Project
The following tips are just stray thoughts based upon experience with using MS Project to manage programs with a few hundred tasks.
1. Create a master project and link to the other projects. This allows multiple project managers to work independently without Project Server.
2. Work iteratively - plug something in and come back later to refine. PMI calls this progressive elaboration.
3. Minimize the hardcoding of dates until the task actually began
4. Keep the tasks in a logical sequence so that dependent tasks are always lower in the schedule than the task they depend upon.
5. Link everything through predecessors so that changing one start date or one duration will cascade through the project.
6. It is acceptable to remove the predecessor once the task is finished as it no longer serves a purpose.
7. Even though you can remove a predecessor relationship one the task starts, leaving it there provides a better explanation as to how this happened.
8. Always add resources to the resource pool before referencing that resource anywhere.
9. Never change the percent completion until the start and end dates are defined the way you want.
10. Save frequently and close the file to make a backup copy every couple hours.
|
References
Advanced Project Portfolio Management and the PMO Gerald I. Kendall, Steven C. Rollins; J. Ross Publishing; 2003; ISBN 1-932159-02-9 One of the best references available on Project Management Offices. Agile Management for Software Engineering David J. Anderson; Prentice Hall; 2003; ISBN 0-13-142460-2 A survey of alternatives and a brief explanation of Cumulative Flow Diagrams for project management. Best Practices for Service Delivery Office of Government Commerce; 2001; ISBN 0-11-330017-4 for paperback or ISBN 0-11-330893-0 for CD The ITIL guide to Service Level, Financial, Capacity, Service Continuity and Availability Management. Best Practices for Service Support Office of Government Commerce; 2000; ISBN 0-11-330015-8 paperback or ISBN 011-330867-1 for CD The ITIL guide to Incident, Problem, Change, Configuration and Release Management. "Cadbury Report" http://rru.worldbank.org/Documents/PapersLinks/1253.pdf. This UK report documented the need for corporate governance. This is one of the key documents in the history of governance. CISA Review Manual 2006 Information Systems Audit and Control Association (ISACA); 2006; ISBN 1-933284-15-3 COBIT 4.0, Control Objectives, Management Guidelines and Maturity Model IT Governance Institute, 2006, ISBN 1-933284-37-4 COBIT Quickstart IT Governance Institute, 2006, ISBN 1-893209-59-8 Combined Code http://www.fsa.gov.uk/pubs/ukla/lr_comcode.pdf The Combined Code was established based on the recommendations from the Cadbury Report and defined governance in the UK. COSO http://www.coso.org “The Committee of Sponsoring Organizations of the Treadway Commission”. The Treadway Commission established the need for separation of duties. COSO reference materials http://www.theiia.org/index.cfm?doc_id=5322 Institute of Internal Auditors reference page with links to COSO materials. Designing a Project Management Office David Foote; http://expertanswercenter.techtarget.com/eac/expertAnswer/0,295208,sid63_gci1157387,00.html A concise article about styles of Project Management Offices. "Directing Change: A guide to governance of project management" Association for Project Management; http://www.apm.org.uk/documentLibrary/97.pdf An excellent, concise and comprehensive summation of the responsibility assignments for effective governance. "Enhancing Corporate Governance in Banking Organizations (1999)" http://www.bis.org/publ/bcbs56.pdf This is the 1999 Basel report that outlined the relationships between management, governance and stakeholders. "Enhancing Corporate Governance in Banking Organizations (2006)" http://www.bis.org/publ/bcbs122.pdf This is the 2006 update to the Basel Report. Exam Cram 2: CISA; Certified Information Systems Auditor Allen Keele, Keith Mortier, and Ed Tittle (ed) Que Publishing; 2005; ISBN 0-7897-3272-6 Guide to the Project Management Body of Knowledge (PMBOK Guide) Project Management Institute; 2004; ISBN 193069945-X; http://www.pmi.org The most widely accepted framework for project management. ISO/IED 20000-1; Information technology - Service management; Part 1: Specification International Standards Organization; 2005 ISO/IED 20000-2; Information technology - Service management; Part 2: Code of Practice International Standards Organization; 2005 IT Control Objectives for Sarbanes-Oxley IT Governance Institute, 2004, ISBN 1-893209-67-9 "IIA response to the Basel Report" http://www.theiia.org/download.cfm?file=66767 The Institute of Internal Auditors response to the 2005 Basel Report includes a diagram showing governance relationships. OECD http://www.oecd.org/ Organization for Economic Co-Operation and Development (OECD). This organization focuses on global governance. OECD Principles of Corporate Governance http://www.oecd.org/dataoecd/32/18/31557724.pdf Organization for Economic Co-Operation and Development (OECD) document with an emphasis on the rights of shareholders. Organizational Project Management Maturity Model (OPM3) Project Management Institute; 2003; ISBN 1-930699-08-5; http://opm3.pmi.org/ An attempt to apply a maturity model to portfolio, program and project management. Practice Standard for Work Breakdown Structures Project Management Institute; 2001; 1-880410-81-8 A goood reference for information about work breakdown structures. "Sarbanes-Oxley (H.R. 3763)" I recommend checking FindLaw for a copy of this legislation. Sarbanes-Oxley; IT Compliance using COBIT and Open Source Tools Christian Lahti and Roderick Peterson Syngress Publishing; 2005; ISBN 1-59749-036-9 "Teamwork Design for PMO Success" Dennis Smith; http://www.chiefprojectofficer.com/article/153 Concise article with an overview of centralized versus decentralized Project Management Offices. "Treadway Commission Report -- “'National Commission on Fradulent Financial Reporting'” http://www.coso.org/NCFFR.pdf This is one of the key documents in the history of governance. The organization that sponsored this work is known as “The Committee of Sponsoring Organizations of the Treadway Commission” -- more commonly known as COSO. "Using Cumulative Flow Diagrams" David J. Anderson; http://bdn.borland.com/article/0,1410,32410,00.html A concise article explaining the technique for using Cumulative Flow Diagrams in project management. "Vigilar Consulting article about Governance Standards" http://www.vigilar.com/sol_compliance_iso.html Overview from Vigilar Consulting on IT Governance. Wikipedia on corporate governance http://en.wikipedia.org/wiki/Corporate_governance Overview of corporate governance with a short history. Wikipedia on the Capro Case http://en.wikipedia.org/wiki/Caparo_Industries_Plc._v_Dickman This legal case triggered governance changes in the UK both through legislation and through the Cadbury Commission. Wikipedia on the Treadway Commission http://en.wikipedia.org/wiki/Committee_of_Sponsoring_Organizations_of_the_Treadway_Commission Brief overview on the committee that established the need for separation of duties. |
About Robert E. Perrine, PMP, ITIL-SM, CISA, MBB