PM-Foundations – My Favorite Project Management Slang

Part of my leadership style as a project manager is not taking myself too seriously. I find that creating a challenging and fun atmosphere on the team helps improve both teamwork and project outcomes. My use of project management slang is something that makes people smile, but also helps make a point in a not too serious manner. Below are a few of my favorite project management slang phrases, as well as some project management phrases that I do not like as well. For those of you that know me, you will recognize quite a few of these phrases, because I am not afraid to use them during daily team interactions.

My 9 Favorite Project Management Slang Phrases

1. In the Weeds – This occurs in team meetings when the discussion gets totally off topic. I see this a lot when the team tries to solve an issue rather than just identify the appropriate action items. This also can occur when a team member heads the wrong direction on a task, or attempts to make a task into something bigger than it was intended to be. “I think we might be in the weeds” is a nice way of saying we need to redirect the discussion or work to focus on the things that are required to keep the project headed in the right direction.

2. Arthritic Abandon – This phrase is definitely one of my personal favorites. Arthritic abandon occurs when teams seem to be working real hard, but are getting very little accomplished. A symptom of arthritic abandon is when team members talk about how busy they are, but you are seeing very little progress actually realized in the project schedule. This phenomenon usually points to the need to reassess how work is performed, or decisions made (e.g., too many meetings, or too many approvals).

3. Religious Discussions – I had a boss that said to me one day, “Do you know the difference between a terrorist and a methodologist? The answer is that you can negotiate with a terrorist.” His point was don’t waste time analyzing and discussing methodologies to get work done – select one that is appropriate for your project and use it consistently and effectively. Obtaining consensus on methods and processes is like trying to convert someone’s religious beliefs – it won’t happen. When I encounter a discussion where it appears that we have reached the core of people’s belief systems, I will make the comment that we may be in a bit of a “religious discussion” where there is no “right” answer. At this point you need to raise the discussion up a level, and agree on a path forward that is acceptable to the team (or if necessary mandate the path forward as the project manager).

4. Solving World Hunger – “Solving world hunger” occurs when the team is attempting to solve something that is too big. I use this phrase to encourage the team to break the problem down into components and identify actions items required to move forward. Another version of this phrase is, “I think we might be trying to boil the ocean.”

5. The Wedding Planner – I have several phrases that describe types of project managers. I don’t use these phrases to be mean, but rather mentor PM’s on adjusting their focus or behaviors. My personal favorite is the wedding planner. The wedding planner is more concerned with planning events (e.g., project celebrations, steering committee meetings, milestone reviews) than managing project outcomes. The wedding planner likes planning logistics related issues (e.g., meeting rooms, invitations, AV equipment and meals) more than resolving issues and completing real work. A couple other project manager terms that I have encountered are:

  • Clipboard Project Manager – This is the project manager that walks around and “checks” off tasks as they are completed. This project manager is usually so busy with the details that they do not notice when a major milestone is slipping.
  • Content Free Project Manager – The content free project manager wants nothing to do with understanding the product that is being delivered by the project – that is “not their job”. If you have ever tried it before, it is very difficult to help resolve issues or complete work with zero comprehension of the solution your team is working on.

6. Dog Knot – A dog knot is when project issues have brought progress on the project to a complete stop. This is also referred to as “gridlock”. Disagreements or confusion related to specific issues can cause teams to lose focus on the actions required to “move forward”. A dog knot situation usually requires intervention on the part of the project manager to facilitate issue resolution.

7. Pushing a Rope Uphill – This phrase refers to team members that are trying to do something that is very difficult, and is unlikely to have a positive outcome. The team member’s idea or effort does not fit well within the goals or strategy of the project or organization. A similar phrase is “going against the grain”. I will us this phrase to get team members to drop the idea or effort in the spirit of gaining consensus on the team.

8. This Dog Won’t Hunt – I was introduced to this phrase when managing a product development effort. When describing the lack of market acceptance for the product, the product manager said, “I don’t think this dog is going to hunt”. This phrase gently conveys the message that the project is delivering a solution that is not going to meet the project objectives. This phrase is used either to help the team decide on the appropriate corrective actions, or recommend to cancel the project.

9. Feeding Frenzy – A feeding frenzy refers to something that can occur in a team meeting. One person says something and it causes the team to go on a wild tangent. Generally the feeding frenzy is not positive (a lot of griping can occur in a feeding frenzy). I use the phrase in an attempt to get the team to calm down a bit, and refocus the discussion on the topic at hand.

Not My Favorite PM Slang Phrases

Here are the phrases that I am not as fond of. I don’t like most of these phrases because they are too negative about the project or the project team. The other reason I do not like some of these phrases is that they touch on aspects of the project that should be managed / solved by the project manager.

  • Scope Creep –Some project managers fall back on the excuse that the project is over budget or late because there were constant changes, but often cannot quickly explain the changes that account for the primary deviations from the original plan. Projects with too high a percentage of unexplained variances, is usually an indication of a project with inadequate attention to change control processes. In these cases, too many changes are “flying under the radar” and hence the use of the term “scope creep”.

  • 9 Women cannot have a baby in one month – This phrase refers to the fact that you cannot just “throw” more resources at a project to deliver on a target date. This phrase is not my favorite mainly because it is overused. I also do not like it because it infers that there are limited options that will fix the problems on the project, even additional resources. I believe the project manager is obligated to work with the team to find options to get a project back on track, especially when the sponsor is offering to help with additional resources.

     

  • Death March – The phrase “death march” refers to a project assignment that is doomed from the start due to unrealistic commitments/expectations (aggressive deadlines, under-funded, and short staffed). Referring to your project as a “death march” from the beginning of the project becomes a self-fulfilling prophesy. Honestly, I have never taken on a project that I felt was a “death march”. If the project commitments truly are unrealistic, the “facts” discovered throughout the planning process can be utilized to help reset expectations.

  • And then there was a miracle – This phase is used when the team feels that the only way a successful project outcome will occur is if something beyond their control happens. As a project manager, I like to believe that the team has been empowered to successfully deliver the project. To say that a “miracle” is required is in essence shirking responsibility for the project results, and/or conceding defeat/failure.
Advertisements

PM-Foundations – The Project Charter

Every project needs to start somewhere. Someone in the organization identifies a new idea, a problem to be solved, or a business need to be fulfilled, and initiates the project through some form of communication to the group that manages the project initiation process. Depending on the organization and the type of project request, the initial communication has different names – project charter, business case, enhancement request, service request, or investment proposal (to name a few).

In my experience, the project initiation process is a critical component of the overall project delivery process because the time lost “up-front” identifying and formalizing new projects is seldom recovered throughout the remainder of the project life cycle. No matter what you call the document that is used to initiate the project, the process and content utilized to capture and approve the project concept will have a significant impact on time to market and reduce the number of “false starts” associated with new project requests. Consistent and well-understood project initiation processes and deliverables makes it “easier to do business” with the project delivery organization.

For purposes of this blog, I refer to the project initiation deliverable as the Project Charter. This is the term most commonly utilized within the project management community, and is often adopted as the name of the project initiation deliverable within organizations’ project delivery processes / methodologies.

Project Charter Content

The information captured within the project charter is utilized to provide a high level description of the project concept (business need or problem to be solved), and answer some basic questions utilized to justify approving initiation of the next step in the project delivery process (project planning and execution).

  • Why? Describes the goals and benefits of completing the project. A good project charter will provide a description of tangible benefits to the organization, including quantification of the potential range of benefits (optimistic – realistic – pessimistic).
  • What? Describes the high level scope of the initiative, and the key requirements associated with the request (often in the form of critical success factors).
  • Who? Provides a list of the primary person/organization requesting the project (the project sponsor), and the key people/organizations impact by the project (stakeholders). It is helpful to describe how the people/organizations are impacted (e.g., suppliers, subject matter experts, end users, customers).
  • When? Highlights timing related requirements associated with fulfillment of the project request (e.g., window of opportunity). In some cases, how the project request will be fulfilled is known, and the project charter provides key project milestones and target dates.
  • How? Describes what is known about the project delivery process. In many cases the project is not starting from a “blank piece of paper”. The project may represent an enhancement to an existing product or system, or the implementation of a product / technology that has already been identified or purchased.
  • How much? Establishes funding available to complete the project request (e.g., amount budgeted in the organization’s budget), and/or cost related parameters associated with fulfilling the project need. In many cases, the project charter will define a rough order of magnitude type estimate for completing the project (e.g., +/- 50%).
  • What else? The charter will include any additional information that is relevant to approving the project request and initiating the next step in the project delivery process (e.g., project assumptions or constraints). The project charter may also include an assessment of risks and issues associated with the project request.

Listed below are elements commonly found in a project charter. Many project charters include a summary section that “scores” the request based upon the initial estimates of benefits, costs, timing, and resources. This score is utilized to help evaluate the relative value of the request (compared to other requests) within the project initiation process.

Elements of an Effective Project Charter:

  • Background / Description
  • Goals & Benefits
  • High Level Scope
  • Key Product Requirements
  • Critical Success Factors
  • Proposed Project Delivery Process
  • Project Sponsor & Key Stakeholders
  • Cost Estimates / Targets
  • Target Dates / Milestones
  • Assumptions & Constraints
  • Known Risk & Issues
  • Score / Ranking

Project Charters do not need to be lengthy documents that represent a long and arduous process to complete. The specific content within the project charter should be tailored based upon the type, size and complexity of the project request. The project charter should be viewed by the customer of the project initiation process as an “enabler” vs. a “blocker” to launching a new project.

Who is Responsible for the Project Charter?

Ultimately the person or group that has identified the business need or problem to be solved is responsible for the project charter. However, in my experience, many areas of the organization do not have the experience, knowledge, or skills required to create an effective project charter. Their “best attempt” frequently does not adequately describe the business need, high level scope, or the best approach to fulfill the need. These project charters are often “hung up” in the project initiation process, requiring significant rework and additional justification prior to approval. Again, delays during project initiation are seldom recovered in the remainder of the project delivery process.

To solve for this problem, I recommend assigning a member of the project office to help the project initiator with gathering and documenting the information required to create a strong project charter. If the person assigned is also the person that is anticipated to be the project manager for the initiative (assuming it is approved), assisting the project initiator with the project charter will streamline the project manager’s on-boarding and ramp-up during the official project launch and planning processes.

6 Attributes of a Good Project Charter

1. Written – Although the initial idea may be communicated and vetted verbally, project initiation requires some form of written documentation to efficiently approve the request and launch the project planning effort. In addition, documenting the project charter enables collaboration of key stakeholders, and improvement of the end deliverable.

2. Objective – The project charter should fairly represent the perspectives of all key parties involved and impacted by the project request. Although the project charter is not intended to be a legally binding document, it is expected to be a reasonable representation of the anticipated benefits, as well as the estimated effort required to fulfill the request.

3. Explicit – A project charter should clearly and concisely communicate each of the key elements of the request – goals/benefits, timing, costs, risks/issues. Based upon the information known at the time the project charter is created, these elements should be described in detail, and quantified if possible. In many cases, the use of project assumptions enables quantification of benefits, costs, and timing. Project charters that contain ambiguous elements are often the source of contention and change during the project planning and execution processes.

4. Available – The project charter should be maintained in a location that is available to all stakeholders. Collaboration on the project charter improves the quality of the end deliverable. In addition, the project charter represents a deliverable that will continue to be referenced throughout the project life cycle, particularly during the project planning process.

5. Consistent – Establish a template for the content and organization of the project charter. Within the template describe how the content can be tailored based upon the size, complexity, and type of request. Best practices and lessons learned from previous projects are used to continue to enhance the project charter template.

6. Approved – As defined by the organization’s project initiation process, the project charter should be approved by the appropriate parties (including sign-off) prior to launching the project planning process. All project charters (in process, approved, and rejected) should be maintained in the project office’s project archives.

PM-Foundations – What Does a Project Manager Do?

One of my favorite questions to ask potential project management candidates is, “When you were managing the project what did you actually do throughout the project delivery process?” It is amazing how vague and ambiguous the responses can be.

“I managed the project deliverables.”

“I led the team.”

“I guided the project.”

“I managed customer relationships.”

“I facilitated project planning.” (this one is a little better)

None of these examples very effectively describe what the project manager actually “does” to ensure the project is planned, executed, and closed in a manner that delivers on customer expectations. The other response that I frequently get to this question is a “deep dive” into the content of what was delivered. For some reason candidates think describing what was delivered articulates their contributions to the project outcomes.

The reason I think it is so important for candidates to be able to clearly describe what they do as a project manager is that it helps identify whether or not they consistently do the right things at the right time during the project delivery process. Focusing on the key elements of what a project manager does is also helpful to identify improvement areas and professional development opportunities when coaching and mentoring project managers. Below are 9 of the project management activities that I focus on when working with project managers. I thought about ranking these in order of importance, but honestly I believe these represent the handful of things that are all important for a project manager effectively and efficiently perform to consistently drive positive project outcomes (therefore these are in no particular order).

Top 9 Things a PM Does throughout the Project Life Cycle

1. Create and Manage the Project Schedule – Without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations. The project manager has direct responsibility for creating the project schedule, including defining the work breakdown structure (WBS), performing activity definition and sequencing, loading and leveling resources, and performing schedule analysis. During project execution the project manager updates the project schedule in a consistent and timely manner. These updates ensure that the project schedule always provides an accurate picture of work completed, and work remaining to be completed.

2. Create and Manage the Project Budget – The project manager creates the project budget by efficiently leveraging the planning assets created to that point in the process. The project manager performs analysis to develop a project budget that will be understood and approved by the client/stakeholders, and just as importantly can be managed throughout the project life cycle. Creating the project budget includes developing a project staffing plan that details planned resource utilization (in hours), identifying other project costs (e.g., software licenses, infrastructure investments, and travel & expenses), and complying with the organization’s financial processes (e.g., capitalization, investment approval, project budgeting vs. funding). During project execution the project manager updates the project budget with actual hours reported by project resources and other actual costs incurred (e.g., from vendor invoices). The project manager forecasts cost variances based upon costs incurred and estimated cost to complete the project, and identifies / implements corrective actions required to deliver the project within budget.

3. Create the Project Plan – The project management plan represents the key deliverable created during the planning phase of the project that connects the project management activities throughout the project life cycle. The project management plan describes the elements of the baseline project plan (scope, timeline, costs and resources), as well as the approach, processes and tools that will be utilized to manage each component of the project (e.g., cost management, schedule management, change management risk management, roles & responsibilities, project communications). The project manager ensures that a strong project management plan is efficiently created (the project manager generally authors a large portion of the project management plan), and is proactively utilized throughout the project life cycle to successfully deliver on the project objectives.

4. Identify and Manage Risks / Issues – Throughout the project life cycle the project manager facilitated the investigation of project related uncertainties to identify potential risks of things that may occur that would impact the project (scope, cost, or timing). The project manager is responsible for capturing and tracking risks and issues in a manner that minimizes their impact on the project. The project manager ensures that key risks and issues are reviewed on a regular basis, and the appropriate actions are completed to close issues or reduce the impact / probability of risks.

5. Manage Team Meetings – The two most important team meetings that the project manager has responsibility for are the core team and steering committee meetings. Effective planning, facilitation and follow-up for these meeting by the project manager is a key to ensuring that the core team members and project sponsors are well-informed, focused on the right things, and resolving issues in a timely manner. The project manager creates the agenda, organizes information to be presented, facilitates the meeting, communicates meeting outcomes, and initiates / tracks the follow-up actions from the meeting.

6. Manage Change – Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The project manager establishes the change control process for the project, ensures that potential changes are captured and assessed in a timely manner, implements approved changes by making the appropriate adjustments to the baseline plans, and tracks / communicates the impact of change on the project.

7. Measure and Manage Project Performance – The project manager updates progress against plans (budget and schedule), performs analysis required to accurately interpret the key project performance metrics, and recommends / implements corrective actions. This process is performed in a consistent and timely manner to ensure that problems are identified early on, and the appropriate actions are taken to keep the project on-track.

8. Facilitate Stakeholder Communications – The project manager communicates with key stakeholders in a regular and consistent manner, targeting the messages to specific stakeholder groups using the appropriate communications channels / vehicles (e.g., project update meetings, status reporting).

9. Close the Project – Project closure represents an activity that is often minimized or entirely overlooked by the project manager. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The second component of closing the project is gathering customer input about the project, and summarizing the project results in the form of the final project report (also known as the project closeout report). This component of closing the project includes facilitating the lessons learned process to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps to improve future projects and upgrade the capabilities of the project office.

How do you know if you are doing the right things?

This represents a long list of things to do on a regular basis – how do you make sure you are focused on the right things? Part of the answer to this question depends on where you are in the project life cycle. During the planning phase your focus is on creating the planning deliverables – the schedule, budget, and project management plan. During the execution phase of the project your focus shifts to updating the schedule and budget, tracking risks and issues, managing change, communicating with key stakeholders, and measuring / managing project performance.

The other element of answering this question relates to establishing a personal organization system that the consistently helps you understand and focus on activities that will have the greatest impact on driving positive project outcomes. Neal Whitten, in one of my favorite project management books, “No-Nonsense Advice for Successful Projects”, talks about ensuring that the project manager is managing the top 3 problems. Neal states, “The No. 1 reason projects run into trouble is that the project manager and other project members lose sight of the problems that need the most attention – the top three problems. The top three problems become the top priorities.” I think this concept relates directly to the everyday life of a project manager. What are the top 3 things that need to be performed / resolved to keep the project moving in the right direction? There are many personal organization techniques that you can use as a project manager to ensure you are focused on the right things. I utilize a project planning pad (see below) to record and prioritize my activities at the beginning of the week. This tool personally helps me maintain focus on the “right things” throughout the week, and summarize accomplishments and open issues at the end of the week. The same organization system does not work for everyone, but my personal opinion is that effective project managers consistently utilize personal organization processes / tools of some shape or form.

 

On a Personal Note: I got the idea to write this blog when I was talking to a good friend of mine the other day, Mark Ducharme, about what people do (at work). He said I know that you are a project manager, but I have no idea what that means in terms of what you actually do when you go to work each day. Thanks for asking Mark!

PM-Foundations – Organizing Your WBS

Creating a well-organized Work Breakdown Structure (WBS) is always on my list of “critical few” project management best practice areas. The WBS is utilized to effectively define the scope of the project, decomposing the work down into components that can be estimated, scheduled, and tracked/controlled throughout the project life cycle. The WBS makes the scope of the project actionable in the form of a deliverable oriented and hierarchical view of the work. The WBS defines the scope of the project down to the lowest level deliverables called work packages.

One of the most common questions I get when discussing the WBS with project teams is, “What is the best way to organize the project deliverables?” A lot of people think the answer must be obvious, because it does not seem to get discussed much by the team when the WBS takes its initial shape / form. It is not at all a stupid question. There are two very different ways that team members think about the project. One way of thinking about the project is focused on the product that is being created, and the other perspective is based upon how the project work will be completed. Selecting one school of thought over the other will drive a totally different end result in terms of the organization of the WBS. As the project manager, you have to live with the organization of your WBS throughout the project life cycle (it drives the organization of the project schedule, as well as the monitoring / controlling processes), therefore you want to be sure you have purposefully selected an organization approach that works for the project team.

Product Based WBS Organization

For those of us with experience in a manufacturing environment, you are familiar with the concept of the bill of material. The bill of material describes how to build a product from the end product down to the lowest level parts or components. The bill of material is utilized to manage building products in a repeatable, efficient, and cost effective manner (automated utilizing an ERP system). When designing or developing a new product, the bill of material is a logical manner to organize the work that needs to be completed. For product development type projects, organizing the WBS in this manner helps the team think about and visualize whether or not they have effectively accounted for and planned all aspects of the product. This approach also provides an understanding of how different aspects of the product are coming together as the product development effort progresses.

Benefits

Downside

  • Provides the ability to trace the components of the product down to the lowest level sub-components
  • Improves the visibility of the current status of product components (particularly important when working with suppliers)
  • Engineers relate well to the WBS organization structure
  • The WBS is not organized from “beginning to end” of the project life cycle
  • Top levels of the WBS remain open until the end of the project
  • Non-product related deliverables do not fit well in the WBS (unless they are define as part of product’s the bill of material structure)

Project Based WBS Organization

As a project manager, I generally think about the project effort in terms of how the work is going to be completed (based upon the timing and dependencies associated with deliverables). With this approach the work is grouped into work streams (sub-projects), and project phases (defined with major milestones). As you get into lower levels of the WBS the organization of deliverables is based upon the different components of the project or product. This approach allows the project manager to update the project “from top to bottom” as the project progresses (assuming the project progresses in pretty much the same manner as it was planned).

Benefits

Downside

  • The “flow” of the WBS relates closely to the way project work will be completed
  • As work is completed, components of the WBS can be “closed”
  • Generally, easier for project managers to update progress
  • Difficult to utilize the WBS to obtain/communicate the “bill of materials” relating to the product
  • Difficult to highlight the status of specific product components
  • Engineers may struggle with understanding the schedule (and often complain about it)

 

What is the Best Fit for My Project?

There are good reasons to organize your WBS from both the product and project perspective. Below are several factors to take into consideration when you are working with your team to determine the best approach for organizing your WBS.

  • Standalone vs. Dependent Work Efforts – Where are the majority of the dependencies and interrelationships within the separate work efforts? Are the dependencies more focused on the product components or the phases of the project? Are the project milestones tied to the product components or gates in the project life cycle? It is much easier to manage dependencies in a vertical manner within a single work stream, rather than in a horizontal manner across multiple work streams.
  • Wide vs. Deep – Based upon my experience, it is much easier to manage a project that has a WBS that is deeper (vertical) than it is wide (horizontal). Part of this preference goes back to the fact that it is easier to manage dependencies within a single work stream (vs. across work streams). However, I also find that it is easier to manage and measure progress of the overall project (solution) if there are fewer separate work streams that link directly to the highest level of the WBS (the over solution / project summary). For example, if there are 15 major product components associated with your project, with significant dependencies across the components, you should have a good case for organizing the WBS around the project life cycle.
  • Who Cares? – Who are going to be the major consumers of the information maintained within the WBS and the project schedule? Is the effort more product or project focused? If it is a very product focused effort, largely comprised of a team of engineers, you may be fighting an uphill battle to suggest that the WBS should be organized based upon the project phases.
  • What Does Progress Look Like? – How will you be receiving updates on project progress? Will progress updates be organized around separate product related work efforts, or based upon the project phases and upcoming project milestones? Again, the answer to these questions will be largely dependent upon the composition and focus of your project team.
  • Iterative Implications – When the team makes the decision to deliver the project in an iterative manner, they are making the decision that the WBS needs to be organized around the iterations. Iterations are time based, and therefore the WBS takes on a project based organization structure (with the project phases being the individual iterations and milestones for deployments).
  • Either approach will work – As you can tell from my analysis above, I am a project manager and obviously favor one approach over the other. The bottom line is, either approach can work for you and the project team. I can honestly say that some of my most successful project were managed with a product based WBS. In some cases additional steps are required in the WBS definition, and schedule set-up to provide views of the schedule / status from both a product and project perspective. This can be accomplished in MS Project by creating custom fields and special views (using sort and filter functions with the custom fields).

PM-Foundations – Creating an Effective Statement of Work (SOW)

Having spent many years on both sides of the table (client and consultant), I have a pretty balanced perspective of what makes partnerships work well. Most importantly I have seen my share of success and challenges as a result of bad client – vendor relationships. These bad relationships are often the source of less optimal project outcomes, or at a minimum the reason the team had to “win ugly”.

I have a firm belief that the quality of the partnership, and the resulting project outcomes, start right up-front when the agreement between the client and vendor is created. The goal of this agreement is to define the products / services the vendor will provide that will satisfy the client’s needs, and how the vendor will be fairly compensated for the products / services delivered. Problems with the agreement can result in a client not getting what they need, or a vendor not getting fairly compensated for what they delivered. Here are a couple scenarios that help illustrate this point:

Scenario 1: The Unhappy Client

The client sends out a Request for Proposal (RFP) to create a new web site. The client has definite ideas in mind in terms of what the new web site needs to look like and do to drive the desired benefits to the organization. The vendor expresses that this project should be pretty straightforward and they provide the lowest time and cost estimates. They are awarded the engagement largely based upon these estimates. As the project progresses, the vendor expresses that there are more requirements / complexities associated with the solution than originally defined in the SOW. Many change orders ensue and the project slips. Finally, the project is completed, but the client had to forgo certain desired features, paid more than planned, and went “live” with the solution much after the original management commitments. This is not a happy client.

Scenario 2: The Damaged Vendor

The vendor provides a proposal to develop a collaboration portal for their client. The client says that they really want to do business with the vendor, but they do not have funding for the amount proposed. The client convinces the vendor that they can “cut some corners” in a couple areas to meet the desired cost of the engagement. As work progresses, client stakeholders keep pushing for doing things “the right way”, and in the spirit of maintaining a positive relationship the vendor performs much of the work originally proposed. The project is delivered successfully, but not without much pain and additional effort on the part of the vendor.

The processes utilized to create and approve the Statement of Work (SOW) can help both parties establish a strong partnership and achieve positive project outcomes. My insights on this topic are not all about introducing overhead and bureaucracy to crank out an “iron clad” contract, but rather how the client and vendor can work collaboratively to create an agreement that sets up both parties for success (the overused term for this is creating “win-win” situation).

6 Tips on Creating an Effective SOW

1. Understanding of the Problem – In my opinion the most important element of creating a strong agreement is ensuring that the problem to be solved is well understood by all parties involved. Adequate effort must be invested in the client describing the problem, the vendor performing discovery to understand the problem and associated requirements, and the vendor describing their approach to solve the problem. Many of my experiences with bad client – vendor relationships can be traced back to when this process was not completed well. I believe that vendors can consistently separate themselves from the competition by taking the extra steps required to understand the client problem, and effectively articulate their proposed approach to solve the problem.

2. Creating an Acceptable Delivery Approach – The processes and tools the vendor will use to deliver the solution must be compatible with client processes and tools (e.g. SDLC, project management tool). In addition, the approach must be one that the vendor is comfortable using to successfully deliver the solution. If there are specific processes or tools that are critical to compliance with client methodologies, they should be understood and specified in the SOW.

3. Establishing Realistic Estimates & Targets – Both parties must be comfortable with the effort and timelines defined in the SOW. Agreeing to estimates or dates that are not reasonable or achievable will lead to problems in the project delivery process. One of my favorite statements is “the work is what it is, and just saying it will be so does not make it so”. If there are specific concerns about the estimates or timelines, it is much easier to discuss and resolve the issues before the work has started, rather than after a significant problem is encountered during the project delivery process.

4. Defining Roles & Responsibilities – Many agreements fall short in the area of defining roles and responsibilities. Vendors do a decent job of describing the resources that they will require to deliver the solution, but they do not spend as much energy on describing client resource requirements. I think it is most effective to describe the client roles and responsibilities in the context of a RACI Chart, and highlight deliverables that the client is responsible for or is making significant contributions to. In addition, it is important to highlight specific resources or skill sets that will be required to complete key deliverables.

5. Minimizing Assumptions – Assumptions are often overused in an agreement to try to protect a party against negative situations. My experience is that these assumptions are forgotten the moment the SOW is signed, and they can become a source of contention during the project delivery process. The classic “CYA” assumption found in many SOWs is “the vendor will have timely access to client resources to define requirements and approve deliverables.” First of all this statement is not actionable, and secondly it is not helpful to successful project delivery. If there are areas of concern, work together to address the issues in an actionable manner either within the definition scope of the engagement or the project delivery approach.

6. Accounting for Progressive Elaboration – Almost all agreements involve “unknowns”. The SOW must accommodate how the unknown will be turned into a known, as well as how project plans will be adjusted throughout the project delivery process. The most common way (but not necessarily the best way) that agreements account for unknowns is through the description of the change order process. A change order process is required when an unknown is not described in the SOW, and requires additional work when it is discovered in the project delivery process. However, many unknowns are associated with clarifications required (vs. change) during the project delivery process and these situations are best accommodated by reflecting iterations in the delivery approach to confirm and adjust plans accordingly.

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.

 

 

 

 

5 Tips to Use SharePoint KPIs to Measure Project Performance

Many project teams spend time talking about project metrics up-front, but then have weak follow-through on actual implementation of the metrics. The one metric tracked within most project offices is the overall status (Green, Yellow, Red), but even then it is often times not supported by factual project performance data. There is data captured throughout the project life cycle that can be presented to provide a better picture of overall project performance.

SharePoint 2010 provides features that enable project teams to expose project data in the form of easy to consume project metrics. The Status List in SharePoint is used to implement project metrics on your project site that are updated as project data is maintained throughout the project life cycle. As with any tool, the hard work lies in defining the metrics and business rules, not adding the metrics to the Status List. This blog provides several tactical tips on how to use the SharePoint Status List to implement project metrics that help measure and improve project performance.

5 Tips to Create Meaningful SharePoint Key Performance Indicators (KPIs)

The following represent several “how to” type tips for creating project metrics within a Status List on your SharePoint 2010 project site.

1. Define what to measure – In many cases the project office will have established standards or guidelines around project metrics utilized to measure project performance. As with all project management best practices you want to select the critical few metrics that will make the biggest impact on project performance. In addition, it is best to focus on metrics that can be produced as a by-product of the project information required to effectively manage the project. I focus on the following best practices areas from a measurement perspective:

  • Schedule Performance – This metric can be derived from the project schedule using earned value, or based upon the schedule variance on key milestones (as a percent of the total duration for the milestone).
  • Cost Performance – This metric is best calculated from the project budget information, either using earned value or based upon budget variance (be careful with budget variances that do not take into consideration some flavor of earned value in the estimate to completion (ETC) calculation).
  • Impact of Change – What impact has approved changes had on the schedule and cost performance of the project? This metric should come straight from the project change control tracking tool.
  • Risks and Issues – This metric is utilized to project the potential impact of high risks and issues on the future performance. This metrics should also be a fairly straight forward extract from the risk and issue tracking tool.
  • Overall Project Status – Some project offices calculate the overall project status (Green, Yellow, or Red) as an aggregate of other project metrics. In most cases, I find it most effective for the project manager to assign the status during the weekly status process as a reflection of the cost and schedule performance, and in the overall health of the project (including trending of the project’s risk profile).

2. Establish the data source – Once you have defined the project metrics, you need to establish the source of the data that will be utilized to update the metric within you SharePoint Status List. The two sources that I utilize are Excel Spreadsheets stored in the document library on your project site (e.g., Cost Performance or Schedule Performance), and a SharePoint List utilized to track specific project information on your project site (e.g., Risks/Issue and Change Control).

  • Excel as the Source – There are a couple steps required to expose data from Excel spreadsheets within the KPI. As previously mentioned the first step is to save the spreadsheet within a document library on your project site. The second step is to utilize the name manager function within Excel to identify the specific cell or range of cells that will be accessed from SharePoint.

Excel’s Name Manager utilized to identify the specific cells to be accessed by SharePoint.


Establish the location and named area when setting up the KPI in the Status List.

  • SharePoint List as the Source – If the information for the KPI is maintained within a SharePoint list, you select the specific list and view (I discuss list views under point #4) from the Site Content displayed.

Select the SharePoint List and View when setting up the KPI in the Status List.

3. Define the parameters – After identifying the source of the data for the KPI, you need to define the parameters that establish the assignment of the metric rating (Green, Yellow, Red). First, establish whether “higher” or “lower than the target value is better for the KPI. Then specify how to determine if the metric is Green, Yellow, or Red.

  • Excel as the Source – The definition of the targets of Green and Yellow are maintained within the Excel Spreadsheet, and you specify these fields (as Named Areas) when setting up the parameters for the KPI. In this example the values in the spreadsheet contain earned value targets for Green (1.0) and Yellow (.90).

  • SharePoint List as the Source – You have options on how to define the KPI from a SharePoint list. It can be based upon a count of the items in the List View, or calculated based a specific field in the List. In the example below the schedule impact was defined based upon the sum of the schedule impact field in the approved change request view of the Change Request Tracking List. In this example the KPI is GREEN if equal to or lower than 10 days total impact, and YELLOW if less than or equal to 20 days (and RED if over 20 days).

4. Create the List Views – When using SharePoint Lists as a source of KPIs in the Status List, you must make sure the List Views are established that support the KPI. This point is best explained with the example below.

  • Impact of Change – If the metric is utilized to communicate the impact of approved change requests on the Schedule, the List View must be filtered to only include changes with “Approved” status. In addition, the view must include any fields that will be utilized to compute the KPI (in this case “Sched Impact” field).

5. Use the Metrics – Now that you have gone to all of the effort to create the project metrics on your project site, make sure you use them to effectively and proactively manage your project. You should understand what caused a KPI to change from GREEN to YELLOW or RED (e.g., a new High Risk, or a slippage in the schedule), and initiate the corrective actions required to move the KPI back to GREEN. In addition, I find it a best practice to include these KPIs in your project status report, as well as corrective actions for YELLOW and RED metrics. Use of the SharePoint Status List to measure and communicate project performance also enables the ability to produce an on-demand / on-line project status report.

PM-Foundations – What Makes Projects FUN?

If you have read several of my blogs, hopefully you have picked up on the fact that I am sincerely passionate about project delivery. I am always energized and motivated when a project delivers tangible benefits to an organization. I like project work so much that it spills over into my personal life. It is personally satisfying to evaluate the “before” and “after” on a home project – even if it is something as simple as planting a garden, painting a room, or cutting the grass. So what is it about projects that people enjoy? There must be something there, because people actually volunteer and/or seek out opportunities to be assigned to a project team.

The intent of this post is to prompt some thoughts on the positive aspects of project work, and what you as the project manager can do to enhance team members’ experiences on a project.

What is fun about projects?

These are several of the aspects of project work that is inherently fun and rewarding for project team members.

  • Sense of accomplishment – There is a definite sense of accomplishment when a deliverable is completed, a milestone is achieved, or project is closed. When a project is closed you can observe benefits realized by the organization as a result of the team’s efforts. When a milestone is achieved you move on to a new phase in the project. In contrast, when you complete operational work, there is another “stack” of the same type of work right behind it, with no apparent end in sight.
  • Something Different – Projects provide opportunities for team members to be exposed to new technologies, business processes, and problems to solve. Exposure to new areas represents huge opportunities for team members to learn and develop both personally and professionally. For those of us that thrive on continuous learning, there is nothing better than being assigned to a new client or project.
  • Involves People – Small projects can be delivered by an individual, but the vast majority of projects involve a team of people assigned to accomplish a common goal. The people assigned to the project bring with them a diverse range of talents, experiences and perspectives/ideas. It is this diversity that ensures that the team’s unified efforts are much greater than the sum of its individual contributions. Assembling a diverse group of people as a new project team can be challenging (forming and storming) but it is ultimately very rewarding as the team starts to work well together (norming and performing). I personally find the broad spectrum of people I meet and work with during projects to be the most amazing element of being a project leader.
  • Recognition – All projects have a certain amount of visibility in the organization, otherwise the resources would not be assigned to it. With visibility comes recognition and potentially rewards when milestones are achieved and projects are successfully completed. Visibility can also result in negative consequences when projects are challenged or fail. Based upon my experiences there is far more upside potential associated with positive project outcomes, than risk of negative consequences associated with challenges or failures.
  • Projects End – By definition projects have a beginning and end. Admittedly, some projects are not as enjoyable as others, but at some point they all will come to an end (some more naturally than others). With the knowledge that the project will end, even the worst of projects can have their moments.

6 Ways Project Managers Can Make Projects More Fun

As a project manager, there are a number of things that you can do to establish a positive project environment – one that team members actually enjoy being a part of. These 6 tips are a combination of applying effective leadership skills, and implementing practical techniques to enhance the project environment. My experience has led me to the conclusion that in most cases creating a positive project environment translates into building a more productive and effective project team.

1. Focus on Teamwork – I spend a lot of time making sure the project team understands they are a team working towards a common objective, and not a bunch of individuals assigned to a project. Establishing a group that works as a team starts with making sure the team understands what we are trying to accomplish, and what success looks like. It also includes ensuring that everyone has internalized what their role is on the team, and how their role connects with the success of the overall project. There are things you can do to make sure the group feels like a team. Schedule regular team interactions (team meetings), provide meaningful project updates, and promote collaboration / interaction. Unless this group has worked together before, it takes some real work and focus on your part to make the group feel and interact like a team. Do not be discourage or give up as the team traverses through the forming and storming phases of creating a team. Your leadership can make a significant difference in terms of how the team works together.

2. Be Enthusiastic – Assuming you are like me, and really enjoy project work, make sure the team knows it. You need to consistently model the attitude and enthusiasm you want the team to feel throughout the project. If the project manager does not believe the team can be successful, who does? It is amazing how quickly the team will get discouraged when you display negative vibes about the project either verbally or non-verbally. The easiest way for me to model a positive and enthusiastic attitude during team interactions is to make sure I really do feel that way. When faced with difficult tasks or people, I remind myself what I enjoy about the challenge the project is providing, the team I am working with, and the opportunity to learn something new. This is a critical tip – do not ignore it.

3. Track & Communicate Priorities – This one sounds pretty straightforward, but it is amazing how quickly team members can get “lost in the weeds” or “in a funk” without timely and relevant information about the project. Team members must understand the team’s top priorities, and how these priorities tie to their individual work assignments. Priorities include upcoming milestones, task assignments, action items from team meetings, as well as high impact issues and risks. I try to keep this information simple and easy to consume / internalize – What did we accomplish last week? Where should we focus next week? What roadblocks need to be removed?

4. “Stretch” the Talent – As the team is forming, it is important to get to know the individual team members. Not only do you need to understand their strengths and weaknesses, but also what are the things that motivate and energize them. If you have insights into team member’s professional development path, you can help align work with the areas where they have talents, are excited about, and/or desire to learn. Aligning work and responsibilities in a manner that gives people a chance to “step up” on the team goes on a long ways towards building a highly motivated team that delivers positive results. The opportunities on the team can be both in the form of specific work assignments, as well as roles (e.g., facilitation of team meetings, coordination of team events).

5. Purposeful Recognition – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team. When given the choice of recognizing an individual or a group effort, I generally opt for recognition of the group (sends the right message as a team, and ensures you do not unintentionally leave someone “off the list”).

6. Close the Project – When you have come this far with the team, do not forget to bring appropriate closure to the effort. Effectively facilitating the lessons learned process helps the team reflect on what was accomplished, how it was accomplished, and what would the team do differently on the next project. This is the opportunity for the team to have a real impact on how projects are completed within your organization in the form of implementing continuous improvement actions. The other important element of project closure is celebrating success. Facilitate a project celebration that helps team members feel good about was accomplished before they rush off to their next assignment.

PM-Foundations – Managing Your Project Issues

To me the most annoying, and sometimes the most disruptive type of project churn is issue related churn. Open issues distract team members from the work at hand, and often slow progress to achieve project milestones. At its worse, more time can be spent talking about issues than project work. If the rate of identifying issues outpaces closing them, the project can be overwhelmed with issues. Projects are paralyzed by project issues when team members cannot complete tasks/deliverables because they are awaiting resolution of project issues.

Significant issue related churn is generally due to the project team not having the appropriate focus or urgency required to close issues. In some situations the team is not empowered to take actions or make decisions required to close issues. In either case, issues that do not close create “baggage” for the team, and eventually create roadblocks or challenges for the project.

Hopefully this blog gets you thinking about how to identify when issues are negatively impacting your project, and what you can do to get them under control. Issues are not a bad thing, as long as you are able to manage them, and not vice versa.

How Do Issues Overwhelm Projects?

Here are some of the common indications that issues may be overwhelming your project, or at minimum impeding progress.

  • Too many – The obvious indication of issue related churn is the number of open issues — especially if there are a significant number marked “high” priority. When there are so many issues that you do not know where to start to get them under control, you probably have too many. When the number of issues becomes significant, you start to see processes like “triage” introduced to identify the ones that “really matter”.
  • They bounce around – Some project teams do not seem to close issues, they just reassign them to someone who needs to have another meeting to discuss the issue. A good way to identify the inability to effectively close issues is to look at the history associated with the issues. When issues are owned by multiple people, and the source of multiple meetings, the team is probably not focusing on the right actions required to close the issue.
  • They keep coming back – One of the most annoying aspects of issue related churn is when closed issues are reopened. This occurs if the either the right people were not involved, or the correct actions were not taken to close the original issue. When this happens multiple times on a project I am not sure if I am more upset with the person that reopens the issues, or the person that did not close it properly in the first place.
  • They appear out of nowhere – Often times an issues is raised that makes you wonder, “I wonder why that was not raised before now?” The earlier a potential problem is identified in the project life cycle, the easier and less costly it is to resolve. Therefore, as issues are identified late in the project, the more disruptive issue resolution becomes. As the project manager, you need to strike a good balance between aggressively managing issue resolution and encouraging team members to identify them. The last thing you want is to have team members keep issues to themselves because they think it will be viewed as a “bad thing” to raise a new issue.

6 Tips to Managing Your Project Issues

  1. Capture – My first tip is pretty obvious. Make sure that as issues are identified they are captured. This means that processes and tools must be established early on in the project to enable identification and tracking of issues. In addition, it is important as the project manager to create an environment where people feel “safe” to raise an issue. Having said that, I do encourage the team to be thinking about ways to address the issue at the time they raise it. The old adage “if you are not part of the solution, you are part of the problem” definitely describes some team members.
  2. Accountability – In my opinion the most important element of effectively managing issues is establishing a single person that truly feels accountable for resolving the issue. Issues are best assigned to people that have something “at stake” in the outcome of resolving the issue. The issues should either have an impact on the component of the project they are responsible for, or have an impact on the component of the product they are responsible for.
  3. Action – When team members are providing updates on issues, the focus should be on what actions have been identified to close the issue. I do not necessarily consider “we have a meeting set up to discuss this issue” to be a very effective next step. The more appropriate action items are focused on what decisions need to be made, analysis performed, or requirements defined to determine how to move forward and resolve the issue.
  4. Measure – As is the case in most project management processes, it is important to have the appropriate metrics in place to manage issues. To establish a high degree of focus and sense of urgency, I prefer to measure and communicate high priority issues in the form of absolute numbers. Metrics like net change and average age are best managed through trend analysis. In addition, it is important to keep track of the overall impact of issues on the project. This metric can be tracked within the change control process.
  5. Close – Ensure that the issue management process includes a step to validate that the issue is actually closed. This step can be as simple as a quick review of the recently closed issues in your core team meetings. It is important that team members agree that the appropriate actions have been taken to permanently solve the problem.
  6. Timeout – If an issue, a group of issues, or the issues in aggregate are truly overwhelming your project it is sometimes appropriate to bite the bullet and call a timeout. This happens when issues are causing the project to miss significant milestones, and corrective actions are not in place to formalize the impact and get the project “back on track”. During the timeout, focused effort should be placed on resolving the high impact issues, reducing the overall number of issues, formalizing the impact of the issues, and rebaselining the plan. I also recommend a quick lessons learned process to identify the source of the problems, and adjustments required to prevent the project team returning to the same place during a future phase of the project.

4 Tips to Using SharePoint Lists to Improve Project Delivery

A SharePoint list represents a great tool to capture and maintain project information in a very structured manner. In addition, the information maintained in the list is more accessible to the team than information maintained “off-line” in tools such as Excel. The most powerful aspect of creating SharePoint lists to enable project delivery processes is that the data captured and displayed in the list can be tailored to meet the specific needs of your project environment by YOU. Creating and maintaining SharePoint lists requires an understanding of how to manage your project site, but does not require deep technical skills (I am your average technical project manager – not a SharePoint architect).

Since I receive so many comments and questions on my blog about how to create and maintain SharePoint lists, I decided to write a blog post that provides more tactical information about how to use SharePoint lists to meet the specific needs of your project. This post provides four pretty basic tips about creating and using SharePoint lists in a manner that makes your project teams more effective or efficient.

TIP #1: Custom vs. Standard Lists

In many of my SharePoint blogs I talk about “starting from a custom list”. The term “custom list” tends to scare people because they relate the term to customization (e.g., requires a programmer to perform the function). Selecting a “custom list” as your starting point just means that you are starting from a blank list that you can add your own columns and views to. SharePoint provides several different preconfigured list templates to use as the starting point to create a new list. I use the following standard SharePoint lists on my project sites to support specific project delivery functions:

  • Contacts – Great for the project team roster. I usually add columns to identify team members that are on the core team and the steering committee.
  • Tasks – This list is best for tracking action items within your project meeting workspaces.
  • Issue Tracking – I tailor this list to track risks and issues (my post on risks and issues provides a lot of detail on this list type).
  • Status List – This is a very unique list that is used to define and display project metrics (my post on measuring project performance provides more details on this type of list).
  • Links – This list is used to provide links to project resources (external or internal sites that are directly or indirectly applicable to your project work).

There are several project processes that I find it easier to start from a blank list than a predefined list available within SharePoint. The roles and responsibilities (RACI), change request tracking, and milestone tracking are all examples of lists that are unique to project delivery best practices, and best to create from a custom list and add the columns required to support the specific process.

TIP #2: Streamlining Data Capture Process

You want to make it as easy as possible for team members to add and update information in the list. The most important aspect of making a list easy to use is that you capture the data that is relevant to the process (and only the data that is relevant to the process). If there are columns in the standard SharePoint list that are not relevant to your specific process, delete them. In addition, it is helpful to order the columns in a sequence that is logical and meaningful to your project teams.

The other aspect of making it easy for project teams to use the list is minimizing the amount of information they are required to type into the form. There are specific column types available that ensure that data is captured in a consistent manner, and reduces the amount of “free form” data entered into the form.

Choices: Provides the ability to capture information from a predefined list of options (using a drop down, radio buttons, or checkboxes). This is used when you want to control the values that are entered by team members. Below is an example of the use of a “choice” type column to capture project phases.

Look-up: The look-up feature is used to access information maintained in a specific field in another list. In this example below, I created a list for project roles and access the list to select the project role within the roles and responsibilities list.

Below is another example of using the look-up feature. I am accessing the project team roster list to assign the specific person within the roles and responsibilities list. In this example, I selected the option to allow multiple values to be selected, providing the ability for multiple team members to be assigned to the deliverable.

Date: For date related information (e.g., completion date, target date, due date), utilize the date and time column type. I will generally set-up the field to capture only the date.


Calculated: Calculations can be used to derive values within the list from other columns maintained in the list. This function is commonly used with dates maintained in the list (e.g., number of days past due). In this example, I use the feature to calculate the overall risk ranking by multiplying the probability times the magnitude (impact) for the risk.


TIP #3: Using Views to Target Stakeholders

Views represent the “window” into the information maintained in your list. It is important to create views that provide the information required for specific stakeholder groups. What your core team member needs to review and update risks on an on-going basis, is different than what your sponsor needs to understand the project’s overall risk profile. The first consideration for creating views for target audiences is related to the columns that are displayed within the view. When creating a view you can select the columns to be displayed, as well as the order in which they are displayed.

SharePoint provides several other features to tailor the list view to meet the needs of your target audience. Below are the features that I utilize the most frequently.

Filtering: This feature provides the ability to limit the items displayed based upon specific columns values. I will frequently utilize filtering to limit the items displayed to “active” or “high priority” items.


Sorting: This feature provides the ability to define the sequence that list items are displayed within the view (providing a primary and secondary sort).


Totals: This feature provides the ability to show a count of list items within the view, or display the sum of specific columns within the view.

TIP #4: Use of Templates

It is a best practice to tailor lists to meet the needs of your project environment “one time”, and then save your new list as a template. As a new project is initiated, you access your organization’s project templates to create the new project site. The definition and creation of templates makes it very easy to create project sites that are preconfigured to meet the needs of your project environment, and also ensures that your project management best practices are enabled in a consistent manner from project to project. Some organizations allow project teams to modify the lists based upon the needs of their specific project, but most organizations “lock down” the templates to limit the project specific tailoring to modifying values captured within columns (and not adding or deleting columns within the list). In addition, a standard set of list views is saved with the template, but most organizations allow project teams to create and modify views to meet their team’s needs.

Within the list settings for the specific list, you will find the ability to save the list as a template.

Below is an example of the information captured when you save a list as a template. Note that you have the ability to save the list with or without the list content. This feature provides the ability to create a template from a project site that is already using the list.