About Managing Projects

"Understand your three capabilities: resources, processes and priorities." - Clayton M. Christensen (1952 - 2020)

Introduction

My introduction to formal project management was when I joined General Electric (GE) Canada, Global Exchange Services (GXS) as a Project Manager. This was a new eCommerce team formed in Mississauga, Ontario, to serve GE clients. We were trained at Netscape (California, USA), one of the leading eCommerce firms at the time, on the Netscape SellerXpert and BuyerXpert products for implementing marketplace exchanges. Prior to that I had the roles of software developer, systems analyst, system administrator and team lead for Internet /Intranet Infrastructure at Scotia McLeod.

I joined GE in May 1998. Since then, my roles were primarily project management as a team lead and subsequently coordinating multiple concurrent projects as a GE senior professional. In these years I’ve had the privilege to hire many people, including qualified PMs. The best PMs I’ve managed take the time to understand the project, ask many questions up-front, understand who the stakeholders are, take initiative thereafter, suggest improvements, raise issues when warranted and require minimum supervision in executing the tasks. I’ve been disappointed several times by certified PMs who, in practice, need too much hand-holding and guidance to perform the basic of tasks. It's not always obvious who is a good PM until you have them in your shop working.

Herein, I’ll provide some insights on what has worked well for me and my teams. I would be negligent if I didn’t touch upon what has not gone so well. Be mindful that this advice may not apply to everyone or every project type. The projects I managed or participated in were primarily in financial services technology and ranged from a couple of hundred of thousand dollars to tens of millions. The formality of practices used in these environments may not apply to every industry segment, although are apt for large enterprises where process formality exists.

In principle, the level of project management process formality was aligned with the level of financial risk and impact to the firm’s operations. For example, a $50K project would not get the same level of formality (process, artifacts and governance oversight) as would a $1M project. Most of the projects I worked on, due to the particularity of the requirements (e.g., buy vs. build, regulatory vs. internal, etc.) were implemented using the traditional waterfall approach. Even a small dollar project with a low financial risk can be detrimental to the business if it does not meet the business requirements. As an example, I had a vendor application that replaced an application’s unsecure login with a new secure login method that required two logins and inadvertently introduced application lockouts thereby causing an increase in back-office workload.

In another section I’ll touch on the benefits of Agile and where in my opinion it fits best into. I’ve overseen both agile and traditional waterfall-based approaches. I believe that each method has a fit for product and application delivery. Below I’ll describe some of the artifacts that worked well for projects that I’ve been involved in. These have ranged from small projects to larger projects and hence not all these would or should be applied for a smaller project.

The largest program I worked on was for a Basel II regulatory implementation (OSFI oversight) as the Requirements Lead. This was a $140M three-year program that required much more governance and formality than anything I, or my peers had ever experienced. This required defining the requirements management and oversight processes to a level that satisfied reporting for OSFI. I would not wish this level of process formality for small projects. The program had many project managers and my team’s role was training and oversight of the Business Analyst’s (BA) requirements.

Below I’ll describe what I’ve seen work well from the various projects I’ve participated on.

Project Formality Guidelines

A risk and impact analysis-based approach needs to be taken as regards the level of adequate formality required for a project. A matrix outlining the level or financial risk and possible negative impact to the firm should be available. This could categorize projects into risk/impact tiers. The level of formality as regards documentation, governance structure should be a product of the risk-based analysis outcome for each project.

For one firm I created a project formality matrix. At this firm, projects below $250K did not have to be managed by the PMO and the technology team were free to determine the methodology. Business required direction as to how these small projects were managed and needed a level of confidence that the technology team considered the right mix of artifacts for the project size. For a formality matrix, several factors considered were the number of external players on the project, their time allocation, the cost of the project, the timeline, the number of internal staff, and the type of project, upgrade or new product.

Some firms may have other factors to consider but this matrix answered the question of how much formality was required. The goal was to introduce an objective assessment as to how the project would be managed, however, there is always a subjective component to decision making that becomes inevitable. For example, a small project may only need a business requirements document and a software deployment plan. A larger, more impactful project may require the full gamut of artifacts and a more significant governance structure. The PM or business lead (product owner) may decide that other artifacts be included. In some firms you may be required to get PMO acceptance for exception if you are planning to bypass project artifacts. At the program level, the program PMO would provide the exception, if warranted.

I worked in one firm where all projects, be they small or large, required the same level of formality. PMs were frustrated by the number of artifacts that had to be completed for smaller projects. A common complaint was that it takes longer to author the artifacts than to develop the application! This was a firm with a one size fits all mentality, which should never be the case. When too much formality is required, people will take shortcuts with documentation quality.

I worked at another firm where a significant amount project of funding was available for documentation. There were literally hundreds of artifacts to be created, the firm took the approach of keeping each document lightly written but to point to the other artifacts for more detail; effectively creating a circular reference of artifacts pointing to each other. We were convinced that no one was actually going to look at each artifact in any depth. In summary, not many people enjoy writing project documentation. Overly documented projects are a burden for the team and of questionable use for the customer. It’s therefore important to achieve the right documentation balance while not adding risk to the success of the project.

Roles and Responsibilities

For projects with participating members from various stakeholders; technology, operations, business, audit, etc. I’ve found it valuable that everyone understands their roles and responsibilities up-front, at the beginning of the project and not during the project. For larger projects a RACI chart is also must. For smaller projects I’ve never used a RACI. Note that the roles and responsibilities description is different from a RACI. The goal of role description is to describe the role’s responsibilities on the project. The RACI is used to define who for an activity is either responsible, accountable, consulted or simply informed. The RACI chart does not describe the role.

At one bank we had an upgrade project that ran three times a year on the same application. The upgrade consisted of bug fixes, new enhancements and regulatory changes. Its budget was $800K. This project involved business analysts (BAs) from various teams, a BA lead, a project manager and several QAs with experience in the various system functional areas. Due to the large number of participants brought in from various areas and factoring the issue of high QA staff turnover, the new folks would not always fully understand what we expected of their role.

During project execution, gaps were identified as to the expectations. Some BAs didn’t believe they were responsible for impact analysis on functional changes of the release. Such gaps could have been identified at the early stages of the release and not further down the project timeline. I created a small project charter that described how each release was managed and who were the stakeholders of the release, their roles, their names, percentage time allocation and contact information. For some projects I would also document their reporting manager should escalation be required in an emergency. This approach worked well to eliminate gap issues. It wasn’t perfect but did set expectations clearly up-front of each project participant.

Roles and Responsibilities Chart Example

I’ve seen other cases where a weak project manager would delegate their work to other project members. With the PM role and expectations clearly laid out it is easier for a manager to enforce the accountability of the role. In some banks the PM is fundamentally a keeper of budgets and timelines but lacks the project leadership to lead the project. At one bank, for maintenance projects under $1M, we convinced the SVP that our team could manage the project end to end and spare the approval process delays of allocating a PMO PM and saving cost for a PM that only managed the budget.

Another benefit to the roles and responsibilities chart is that if someone is assigned to the project and does not agree with the role or the outlined responsibilities, it is an opportunity at the onset to clarify expectations or assign someone else. Specifying the percentage of time required is also good as some groups, QA as an example, are allocated to multiple projects and may have time allocation problems with the required time. Better to know these issues in advance. Often, the role description and RACI are part of a project charter or embedded in another document. For large programs, this may be a separate document describing the roles across multiple projects.

Decision Log

I must admit I have not seen too many people keeping one of these. However, it’s been useful to me for those projects with multiple stakeholders from various areas and with long timelines. On a multi-year program I participated on, one of the challenges after 12 months was recalling who had made decisions on aspects of how projects were to be managed. It’s difficult to pull up e-mails of decisions made many months prior to an issue. My experience has been that it’s often difficult to find these e-mails, unless the PM has the foresight to create an e-mail folder. My preference is to copy the text or e-mail into a document log, separate from the e-mail folders (e.g., Outlook folders). If it’s in an Outlook folder, then it’s gone with the PM once the project concludes.

Decisions that have an important impact on the project or its artifacts should be documented. For example, in one project a decision not to have a formal architect review of the technical specifications was made. Another case was a decision that if a project within the program was time constrained some of the review processes could be exempted with the program manager’s (PgM) sign off. These signed off artifacts had to be kept in case the project was audited by the Project Management Office (PMO). The PgM’s decision that some projects could be exempted was documented, so in year 2 or 3 of the program we would know who allowed exemptions.

On the Basel program the requirements team ran into a dispute with one of the PMs due to the requirements review process we facilitated. Their concern was with the review process overhead was impeding their project timelines. The PM escalated the concern to the project PMO. The program’s PMO was hesitant to provide an exemption. Because we did not document the PgM’s directive that all business requirements were to be reviewed and signed off by the architecture board, QA and business analysts from impacted projects, the PM was not aware this was a PgM decision. Instead, the PM blamed the Requirements Management Team (RMT) for adding a burdensome review process. Although the decision was discussed at the PgM’s senior leadership team, without a documented it we could not show evidence this was a PgM directive.

At another firm, a project was initiated to consolidate two data processing centers. The equipment from one data center would be moved to the second data center. A decision was made by the executive that some legacy systems would be left behind and sold for scrap while others of the same model would be moved. Given that the equipment was originally expensive, still functional and rare, it was important to document the decision. From a planning perspective we knew what equipment could be moved, what stayed behind and why as well as the origin of the decision.

Small projects don’t require this level of formality as the timeline from start to end may be several months. We can often recall decisions made within that timeframe. Longer term projects with various stakeholders coming and going is where I found this to be useful. We tend to forget who made decisions during project initiation that may be questioned many months later.

Exception Log

An exception log was used on a large multi-year program to document when process exceptions were granted to some projects. For example, an exception to exclude the requirements review process or an exception to use a shortened requirements document, would be documented. Two reasons for using this: for subsequent PMO audits and to serve as a record as to what exceptions were made, for what project, rationale and who authorized the exception. For most projects this is not required but is useful for programs with multiple concurrent projects and tight timelines whereby sometimes exceptions to process are made.

Issue Log

Every project I’ve been on has issues. If the project does not have any issues, then something is amiss. The issue log documents the issue, its priority to resolve, who is going to remediate it and by when. Some logs also contain a percentage complete column, but I have not seen many maintain this level of detail. As issues are discovered, they are documented. Issues can be wide ranging and can range from resourcing issues (e.g., SAP HR module change is required, need to secure an ABAP developer within 2 weeks), to budget allocation issues (e.g., additional $100K required for product integration with app Z), to tracking of on-going bug fixes.

On several occasions I’ve seen the issues log persist beyond the project and into product production. One such example is code bug fixes or feature enhancements. Sometimes projects need to meet a fixed deadline (either regulatory or due to executive commitments previously made) and in these cases the project does not have the time to resolve all outstanding issues. The product goes into production and the issues are resolved as part of application releases into production.

Bug fixes are either remediated by the development team, which in some firms continues to support the application post deployment by the application vendor or a third party contracted to write the app. Bug fixes, enhancements (e.g., a management report was scoped as part of the project but there was no time to develop) continue to be tracked until all issues are resolved.

Of importance is there must be a way to track issues during the project and after the application goes into production. The PM usually moves on to other projects once the application is in production. The issue log is handed off to the product owner (aka: business representative) to manage thereafter. Reviewed weekly by the project team.

Risk Log

The risk log tracks identified risks to the project, their impact on the project, the probability of the risk occurring, the risk mitigation steps and who is (person or team) responsible for mitigating the risk. The risk log should be reviewed weekly by the project team.

One project I participated on, involved new technology, a new team to be built with 25% current staff, 75% contractors and vague client requirements to start with. Each one of these factors presented a high risk to the firm. These risks were identified at project scoping, as high, with possible project failure and cost overruns. The executive was made aware of the risks but this project being a multi-million-dollar development effort that a client was willing to fund at a fixed cost, the decision was to proceed despite the risks. This was one of the biggest (scope and price) projects the firm had undertaken.

The project team successfully delivered the application to the client as per contract. However, the team experienced a steep learning curve (process and technology), experienced high contractor turnover and loss of knowledge. A third-party firm had to be hired to add additional capacity, requirements were more complex than initially expected, QA was understaffed for the level of testing, along with many other issues. The result was a cost overrun of 30% to the firm.

Change Log

A change log is normally kept for the duration of the project to document any changes made to the project’s scope, timelines and budget. Also tracked are who initiated the change request and who approved the request. The request is normally referred to as a Project Change Request (PCR). This is similar to the decision log, but this log is focused on scope, time and budget. For example, the project determines that an additional report is needed, the project manager raises the PCR requesting the change to scope, the additional cost to the project and the impact on delivery timelines. These requests are requested by the business and need to be approved by the project sponsor, be it the business or technology executive.

Changes to scope are normal for larger projects. These changes can impact project budget and delivery timelines. An executive may deny the PCR due to impact on delivery timelines or budget not being available. In some cases, additional scope creep can be accommodated post project through the application support or enhancement budgets, post-deployment.

Excessive PCRs may point to inadequate scope planning, causing unplanned scope creep during project execution. Unforeseen technology or resource issues may also lead to excessive PCRS. Budget/Financial Plan.

Budget

On-going budget burndown tracking is required for any project to determine how funding is being used and what percentage of functionality is being delivered in comparison to funding availability. Before the project is initiated, either the business or technology rep, or both working together, would determine the approximate cost to deliver an application.

The high-level requirements would have been created by the business. The application development team would estimate what resources are required (developers, QA, etc.) and creates an estimate of time to deliver the work, train staff and deploy the application. This determines the cost (how much will the business spend) and the delivery timeline (when can the business get the app). The sponsoring executive(s) will review the high-level estimates and approve the project with x$ of funding. Normally a small percentage (e.g., 10%) is added as a contingency for resolving unplanned project issues, changes to scope, timelines, resources, etc.

Project Budget Tracking Example

For small project with a short timeline, the budget should be reviewed weekly. On larger programs with many workstreams and projects the budget is typically reviewed monthly. PMs and PgMs need to keep an eye on cash burn and whether the project is sufficiently funded to deliver the agreed upon scope. A useful measure, as mentioned previously, is % of cash spent versus % of functionality delivered. A project with 50% of cash spent and only 20% of functionality completed would be a red flag for the governance board. Both large and small projects need to focus on the cash burn rate.

Project Schedule

The project schedule should be created at project initiation. This is usually a Gannt charted produced with software such as Microsoft Project, Niku, Microsoft Visio, Excel or other planning software. The schedule takes into account the various tasks that comprise the project, participants responsible for each task and time taken to complete the task. Project milestones are also listed as markers of progress. The software allows resources to be added with their available hours, then the PM can see how the resource is allocated over the various tasks and if said resource is over or under allocated.

A resource that is allocated to 10 tasks and their total time commitment in any one week is 50 hours is a problem. Resourcing demand must be flattened out to prevent overburdening resources. Either re- arrange the tasks to flatten the resource demand or allocate additional resources to the same tasks. Resource balancing is one of the advantages a schedule.

The schedule contains predecessor and successor task relationships. So, if a task requires more or less time, the PM can see what the impact is on the other tasks in the project. For example, a task may require more time that now pushes successor tasks beyond a project deadline. This necessitates a PM to re-balance tasks and possibly seek more task parallelism.

Gannt Schedule Example

Another advantage of the schedule is to identify the “critical path”, in effect the longest path of serial predecessor / successor tasks that defines the length of the project. If any task in the critical path requires more time, it is possible that this may push the deadline beyond the project deadline. Likewise, if a task in the critical path requires less time, the tasks may still form the critical path or, another series of task relationships may become the new critical path. In effect, reducing task time on the critical path may create other tasks that become a new critical path. Having a schedule is beneficial when the PM needs to “crash” the project schedule by examining what tasks can be parallelized.

Some folks have confused a project plan with a project schedule. When you think of a project plan, think of a project charter. The project schedule is very different from a plan. The usefulness of the schedule is to literally get a view of all the tasks in the project and their interdependencies for the PM and other project stakeholders. If the business decides to increase project scope the project schedule can quickly evaluate the impact to resource availability and project timelines. For projects with many tasks, resources and milestones, a project schedule is a must. It’s also a great visual communication tool.

Deployment Plan

Some firms require that once a project completes the application, that a deployment plan be created to outline how the application will be moved from the test environment (e.g., System Integration Test) to production. In most large firms the staff who developed the application are not the same people who move the application into production. A hand-off from the development team to the production team is the norm. Although, I’ve worked in smaller firms where change the management process was weak and developers had access to production systems.

The deployment plan outlines when the application will be moved into production, the participants required for the move, their contact information, escalation contacts, the change request ticket number (most firms require a change ticket to be created for any changes to production), backout strategy if the deployment fails, location of the application files and any scripts required for deployment. The plan outlines what activities will pe performed, by when and by who. The latter is similar to a small project schedule, outlining activities and who does what from deployment start to finish.

Some projects may have multiple phased deployments and will require a deployment plan per phase. In my experience most PMs don’t enjoy completing these documents, due to effort to prepare. However, I’ve been on projects where the deployment fails and then you need to know who to call to fix the problem or backout the application. On one project, the vendor deployed an application release that failed business regression tests. We tried to contact the vendor at the number provided, but no answer. Fortunately, we had multiple vendor contact numbers and one other vendor rep eventually answered and repaired the code. This happened occasionally with other vendors, so it’s important to have a comprehensive deployment plan with multiple contacts.

Project Closure Plan / Transition Plan

I’ve used one of these on a large program. Every project I’ve been a part of also had a transition plan from project mode to support. A closure plan is normally for larger programs/projects, but I’ve added it here because it’s usually forgotten as a project completes. The project closure plan is fundamentally a checklist of activities that should occur before the project is terminated and the project team disbanded. As mentioned previously, this is more for large programs with multiple projects. Among the activities are:

1. Determine where project artifacts will be kept for subsequent support needs (e.g., SharePoint, File Folders, JIRA, etc.).
2. Archive project artifacts such as risk logs, issues, change logs, decision logs, lessons learned and any other artifacts that will be used in future to understand the project’s implementation.
3. Inform application production support team where documentation was saved.
4. Check that application support has been trained on the application so it can be supported.
5. Define the timelines for transition from project mode to support mode.
6. Closeout contractor engagements: pay contractor invoices, reclaim laptops, access passes, revoke login credentials and remove login access. Pay vendor invoices as applicable.
7. Shut down any test environments spun up for the project that will not be needed once in production.
8. Close out project time tracking, so staff can lo longer bill time against the project budget.

Project closure and transition plans are similar. The transition plan will also have to consider who will support the application in production, have a transition session describing how the application works (functionality at a high level, architecture, other system dependencies, etc.) have a contract walkthrough to be familiar with any Level Agreements (SLAs or OLAs) and be aware of any third-party contract obligations.

In one firm, my team was the recipient of a completed project. Unfortunately, the PM didn’t inform us of an ongoing agreement for a vendor hosted training environment that we were now committed to pay for the next 12 months. We also realized that Strategic Sourcing insisted on an escrow agreement between the vendor and a third-party escrow firm that also had to be paid for annually. A transition from the project to downstream support teams is required, but sometimes, not all information is conveyed.

Post Implementation Review (PIR)

Also known as a lessons learned review. Normally these are conducted for larger projects that have been implemented over a longer time frame. The goal is to learn what worked, what went wrong and how it can be remediated for the next time. If an external third party was involved with the project (e.g., vendor), then they should also be included in the feedback.

On a year-long project with multiple phases, the data collection method used was a survey. The user input was anonymous, thereby allowing everyone to be open with their feedback. Once the data was collected a PIR meeting was scheduled and the feedback reviewed. It’s important to keep the feedback so that next time a similar or same project is run, a PM can determine if any previous identified issues have re-surfaced.

The vendors appreciate being involved in the PIR feedback review. We did not include the vendor in the feedback input but in hindsight thy should have been. We did provide the internal firm feedback to the vendor so they could improve issues the firm came across. The focus of the PIR was more to improve our own practices on a “continuous improvement” effort.

Status Reporting

Status Report be it weekly or monthly, project sponsors want to know, in brief, how the project is progressing. The best status reports I’ve seen are on one page. In these are the financial status, work completed, what will be done next, any issues (resources, budget, scope) and overall project status (green, yellow, red). If there are project risks or constraints that an executive should know, then this is the place for it. If the project is in red or yellow status, a plan to get to green should be outlined as well. The requirement is that for an audience to consume the status quickly it should be visually well laid out and above all brief, just the facts. The report initiates discussion, it does not have to contain all the minute detail.

Project Charter

A project charter is suggested for projects of all sizes, namely because it forces the PM and the project team to consider various aspects of the project, in effect, treat it as a project checklist. A project charter has also been referred to by some as a project plan. Documenting why a project is needed, what is changing, who needs to be involved at what cost, the risks, assumptions and constraints ensures thought is given to the many aspects of the project. Many of the artifacts mentioned above, are within a project charter in briefer format. For many projects, the project charter is a living document that encompasses many of the items covered previously. Unfortunately, this takes time to prepare and it’s difficult to get people interested in doing this, especially in firms that are resource constrained and staff is already overburdened. Documentation (lack thereof) is always the victim of overburdened organizations.

My experience has been with technology project charters. A project charter template will not be applicable to all industries albeit sectional commonalities. Therefore each industry will likely have charters suited for the particulars of their needs. A charter for a technology infrastructure project will likely not have the same structure as one for Canada's Ministry of Housing.

Among the items a project charter encompasses are:

Project Introduction: Includes the Project Name, Project Manager, Project Sponsor and an Introduction paragraph describing the project. As this is an introductory section, the remaining sections are really high level.

Purpose of the Project . The reason this project is undertaken and for whom. Projects are created to meet a market demand, business need, customer request, legal requirement or technology update. Briefly describe the purpose.

Project Identification Example

Drivers: What is driving the need for the project. Is it a strategic market entry, first mover advantage over a competitor or upgrading an application due to technology obsolescence.

Strategy: How will the project be executed; will there be a limited pilot run first? Is this a vendor solution or will it be built in-house? Contractors, full-time staff or a combination of resources utilized? What applications have been identified and what is the application that will form the basis of this project? What vendors have been selected, if any?

Project Scope: What functionality is in-scope of this project as well as what is out of scope. Need to define the boundaries of the project by explaining what it will encompass and what it will not do. This is not the same as the Business Requirements Document, where the functional requirements are outlined, but rather at a higher level what the project will do and won’t do. It’s mean to sent boundaries around what will be delivered and prevent scope “gold plating” (additional nice to haves to end up adding cost and time to projects).

Project Scope Example

Note that business requirements should be in the Business Requirements Document (BRD) and not in a charter document.

Project Parameters:

1. Project funding: the funds made available for the project, contingency funds, what portion are labor costs versus infrastructure or hardware costs, licensing costs, expected re-occurring annual post project costs (e.g., software licenses); a cost breakdown of the project. Include any non-qualified costs at the time of the project (e.g., components not yet estimated).
2. Benefits: outline the expected tangible benefits of the project (e.g., cost savings) as well as intangible benefits of the project (e.g., avoid technical obsolescence). A schedule of tangible financial benefits over 4 years and a total should be listed. The benefits in the first years may be lower due to capex recovery and better in subsequent years. It’s important to lay out the benefits over multiple years with the total benefit shown for this period.
3. On-Going Costs: what are the costs that will be required to sustain the application or service over the next 4 years, as an example. This should be shown over several years.
4. Known Constraints: what constraints are known at the beginning of this project. Examples are, deadlines, budget, limited availability of resources (people, facilities, equipment).
5. Assumptions: what assumptions are made at the beginning of the project (e.g., required project skills are available within the department, the project will achieve an annual savings in year 2 of $1M, the network has sufficient bandwidth to support the new application, etc.)? Can it be assumed that there is a warranty period by which the project team will support the application once in production. I’ve also seen some projects outlining “Facts” in addition to assumptions. An assumption may be false or incorrect, but a fact is true; unchanging. Facts are factors known to be true and can impact how the project. For example, a fact would be that the project will have four IIROC regulatory reviews. The project will use Microsoft Azure as the cloud provider, is another fact, not an assumption (perhaps how this came to be a fact should be in the decision log!). Facts should not be confused with constraints. A constraint is a limiting factor for a project. A fact is a statement of something that will not change, can influence the project, but is not a limitation on the project.
6. Architecture: factors affecting the project related to architecture. For example, does the application require high availability? If so, this will have an impact on required infrastructure and cost for redundant hardware. Will the application run hot-hot, or will the redundant servers be off-line? What type of technology is required (mainframe, distributed servers, cloud, etc.)? What is the required uptime (e.g., 99.5%) and how will that be achieved. Is there connectivity required for the cloud service or to access an external vendor? Will a network bandwidth analysis be part of the project scope? Are there any new data protocols being used (e.g., streaming, SFTP, Connect Direct, etc.)?
7. Business Context Diagram: a high level diagram showing the business as a black box and identifies the entities that will provide inputs or will deliver services from the business opportunity. Examples are, clients, regulators, vendors other internal departments as inputs or outputs.
8. Dependencies: this section is added in case there are any dependencies on other project completing before this one can begin or if downstream projects are depending on the completion of this project before they can begin. This is typical of large programs where there are many predecessor / successor relationships due to project interdependencies.
9. Project Completion Criteria: defines what is the criteria for the project to be defined as completed. For example, business and technology sponsor signoffs are usually required, successful completion of all application functionality, a successful deployment into production. Some projects define success if the application is in production yet may have a limited number of severity 3 and 4 issues. The business may want to accept some application defects in production if they are not too impactful to meet certain timelines or commitments made. Severity 1 and 2 issues would not be acceptable for an application going into production.
10. Project Charter Schedule: the project schedule is not meant to be a detailed project schedule, but rather at a high level. The schedule will have the project’s significant dates; project start, end and milestone dates (e.g., Funding availability, design reviews, JAD sessions, UAT testing start, deployment date, transition to support, etc.). Often overlooked is the user training and updated documentation effort required when an application is updated or newly introduced.

    You also have to take into account the culture of the organization when using formal project scheduling methods. In most organizations I’ve worked for, project schedules are created at a high-level using Excel. Large programs with hundreds of steps have been those which have used Microsoft Project (MS- Project).

    When I managed SAP maintenance for one bank, I created a project schedule that showed the various activities the team was undertaking so we could better plan delivery and staff capacity. We had many small development projects on the go, as well as maintenance activities, so the schedule was extensive. However, every time I dragged out the schedule to evaluate a new project ask, people would roll their eyes. No one ever used MS-Project to schedule resources and tasks; it was a culture of spreadsheets. MS-Project was regarded as over burdensome and very few people took the time to use it.

    Visio Based Schedule Example

    

    At another firm I used a high-level MS-Visio project schedule. I was literally yelled at by the PMO Manager for putting dates on a proposed project schedule. The issue was that the PMO did not want to be tied down to dates as the executives would expect them to stick to the proposed dates. Explaining it was a planning schedule, not a committed schedule, resulted in an escalation to my VP by the PMO. The lesson learned is, know the firm’s culture. If you are personally comfortable using formal planning methods, it may not fit with your peers’ ways of working and may cause conflict.

    I personally prefer using MS-Visio’s project module for planning small projects with no more than 20 activities. It allows predecessor and successor tasks to be defined. As well, changing the duration of any tasks, automatically adjusts the successor task timelines. It also allows entry of milestones. For programs consisting of many projects, I find that Microsoft Project is a must for managing such complexity of tasks and dependencies. For smaller projects, MS-Visio is great. However, must firms I’ve worked for prefer to use Excel to schedule tasks for small projects.

11. Project Governance: the governance structure needs to be considered. Included are the executive business or technology sponsor of the project, the reporting structure of the project, who provides status reports to who and how frequently. If escalation on decisions or awareness on delays, who is communicated to and how often. Are project reviews performed in person, by e-mail or virtually? How often does the project team meet with the executives, bi-weekly, monthly? How often does the project team meet with the project team, weekly? Communication Plan Example

    

12. Project Participants: This is a list of the people working on the project, their role and contact details. If external vendors are used, it should have their contact information and role as well. The percent allocation of each resource should be in the project schedule and not in the participant table. Roles and Responsibilities.

    The roles and responsibilities need to be outlined in the project charter so that each project participant participating on the project clearly understands their responsibilities. I find that maintaining separate roles and responsibilities tables for Business, Technical Team, Infrastructure and vendors is easier to read rather than lumping all participants in one long table.

    Project Roles and Responsibilities Sample

    

13. Approval Block: If the charter does not have to be signed off by any stakeholder, then the approval block with signoffs is not needed. Nowadays, approvals are usually by e-mail rather than by inked signature. I’ve seen cases where the e-mail is added to the approval block instead of an inked signature. Formal approval blocks, in my experience, are infrequently used. Again, know your organizational processes and culture.
14. Glossary: The last section of the charter should be the project glossary that explains acronyms used throughout the document. Technology organizations are rife with acronyms.

    Glossary Example

    

In Summary

As a final note, this level of formality and documentation is certainly not for everyone or for every project. Most PMs don’t enjoy writing excessive documents. Smaller projects will still benefit from scaling down the project charter. However, I’ve found the project charter useful for having a PM think about the project and the various facets of the application or service that is being undertaken before project execution begins.

The documents above are examples of what I’ve seen used and what has worked well for me. I’m sure that some readers may find this over burdensome. It’s not a fit for every organization or every project type. For software development projects, an Agile approach along with adequate documentation is a great approach. Large regulatory projects where the requirements are well defined in advance by regulators, a traditional project management approach works well. Where requirements are not well defined, an Agile, incremental approach may be best suited. Where requirements are well defined in advance and scope change is minimal, the traditional linear project management approach works well.

I’ve noticed that most programs run under a traditional approach whereby underlying projects within the program may use an Agile or traditional approach. A balanced hybrid approach works best for large programs where the benefit of each methodology improves the program’s chance of succeeding. Firms continually seek to lower project costs, always looking for a magic bullet that will successfully deliver a product or service at low cost. The PM must keep in mind the triple constraints (cost, scope, time) affecting product quality. Cut the cost, crash the schedule to meet a deadline or add additional scope without changing the other constraints and the quality of the product may suffer. There is no silver bullet for scrimping on cost and maintaining quality; this is evident from vendor products we’ve received that had significant defects.

For one vendor application my team managed, it took four releases until it was stable enough to be promoted into production. Every time we received a release it would take two weeks of our QA effort to test. This release had a QA cost overrun of approximately $90K. Every failed vendor release is a cost to the firm. We tried to recoup our QA costs form the vendor but failed as remedies were not defined in the contract.

It’s important to have code quality parameters defined in contracts with associated remedies and penalties. Otherwise, a vendor can rush QA of their product to save cost and push the burden onto the client. This is why it’s important to define what levels of defect severity an application is willing to assume before being moved into production. Fortunately, not all vendors behave this way, but I’ve experienced this with a few vendor deliverables.

Note: High level requirements are normally not in a project charter. I’ve seen some charters where the PM has added the high-level functional requirements. Normally, requirements are within a BRD. I’ve also seen non-functional requirements (e.g., application login response time, availability, maximum number of concurrent users, etc.) in a project charter. My view is that both functional and non- functional requirements should be in the BRD and not in a charter.

Factors that have impeded success...

The following are factors that I've observed impede project success. There are likely more, but this is a small list of the factors I can recall.

1. Failing to take into account the amount of team meeting time that consumes project costs.
2. Failing to perform a stakeholder analysis. This resulted in some stakeholders being brought in late into the project or their participation missed altogether. One project I led on was to develop a web-based client portal for self-managing their user’s access to a banking application. Everyone thought this was a wonderful idea as it would reduce calls to the Help Desk whenever a client user forgot their password or needed to add more users to an application. Funding for $600K was approved for 18 months. Halfway through the project the business manager informed us that this application already had a web-based interface for the client to retrieve business documents. Having two portals with divergent requirements would only confuse the client. This was clearly a failure of not involving the business form the start and realizing there was already another portal in place. An opportunity to enhance the existing portal was missed.
3. Leaving out the time and cost associated with training requirements.
4. Forgetting to account the time to update documentation (e.g., process changes, support guides, job aids, etc.).
5. Crashing project schedules. I’ve seen many times where executives are late to make a decision on whether to pursue a project or not. When the go-ahead is finally given, the timeline to deliver is usually constrained either due to customer commitments made or regulatory deadlines to be met. This puts a project team at a disadvantage as everyone has to work longer hours to meet the timeline. One project I heard of ran for three months, seven days a week, with no downtime for the project staff. I hypothesize there is a positive correlation between the project cost and the time taken for executives to provide the go-ahead. Costly projects or programs seem to take longer for executives to approve and thereby add schedule risk.
6. Insufficient funding. I’ve seen PMs wanting to deliver their project within budget and on time because that’s how they are measured and compensated for their bonus. So, some minor features (e.g., reports, bug fixes, etc.) that would increase project scope/cost are moved over to the support team to continue to develop once the project is closed with the excuse that there are no more project funds. The development team, post-project, now has the additional burden to not only support the application but develop the additional scope left out due to cost. Meanwhile, the PM looks like a rock star for having delivered the project on time and budget.
7. Bypassing processes due to time crunch or process apathy. The reality is that no one is a fan of writing documents. Some folks don’t really write all that well and struggle with documentation. Some technically oriented folks are simply not interested in writing any documentation. I had some developers assert they want to code, not write specifications, after all someone can read the code to understand how it works! One bank’s PMO audited several projects to understand how the projects were being executed. The PMO realized that project processes, artifacts and standards were all available to PMs, but they were not following the standards set forth. Great PMO processes and templates in place, however weakly used by projects!
8. Measuring for on-time and on-cost project delivery while neglecting client satisfaction with the product.
9. Unavailability of skilled project resources. This occurs when a resource is needed from another team but due to an unplanned event, they are not available when needed. The result is the project team burns time and cash waiting for the resource to be available. Normally, a team can focus on other activities, but it does happen that the project stalls. One example from my experience; an application to be delivered by a vendor for the QA team to test slipped delivery by a week due to failures at unit testing. As the QA team could not be disbanded for a week, they had to be paid while they waited for the vendor’s application to be ready to test.
10. Lack of leadership. In a bank I worked at, the PM’s role was to keep track of finances and timelines. I had expected that the PMs would take more of a leadership role and manage the project, not just the finances. Further, every time we initiated a project, we would go to the PMO and request a PM. We soon realized that we could manage our own budget, timelines and provide the necessary leadership. Going forward we eliminated the role of the PM. A PM must to lead the project, budget and schedule, report status and be the liaison between the project team and the executive among other leadership duties.

Reference Links

Below is a list of links relating to the items discussed above.

• click here - Sample Project Charter: Climate Change Adaptation: Transitioning to a Climate-Based (Forest Tree) Genetic Resource Conservation and Management System in British Columbia.
• click here - Government of Canada, Project Charter Guide.
• click here - PMI.org. The Charter, selling your project.
• click here - PMI.org. Evaluation and application of a project charter template to improve the project planning process.
• click here - Government of Canada. Job aid, Risk Management Essentials: Risk Register Template.
• click here - Government of Canada. Public Services and Procurement, Public Services, Risk Register.

Resources

Below is list of documents that have been uploaded to this site and are available by clicking on the links below.

• click here - Sample Risk Register (Excel).
• click here - CDC Risk Management Log (Excel.
• click here - Sample Decision Log (Excel).
• click here - City of Winnipeg (Canada), Decision Log (Excel)).
• click here - Government of Canada. Project Charter Template (doc). This NPMS document template is based on the Treasury Board Project Charter Template.
• click here - State of Georgia (USA). Project Charter Template (doc).
• click here - EERE Web/Digital Project Charter (doc).
• click here - Government of Alberta, Canada, Health Services Project Charter Template (doc).
• click here - City of Winnipeg, Canada, project charter template (doc).
• click here - Center for Disease Control (CDC), sample project charter (doc).

Compiled on 04-24-2024 19:32:35