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.

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.

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 – 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.

Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment. Creating a more productive project environment helps you launch the continuous improvement phase of your Project Management “Best Practices” program from a more efficient and effective starting point. Key elements of a more productive project environment include:

Collaboration – Enhancing your project environment to create more effective interaction between team members.

  • Providing a single source for the truth
  • Upgrading version control for key project artifacts
  • Establishing closed loop communications

Streamlining Processes – Utilizing a tool to establish or enhance project management related processes.

  • Establish structure via lists and libraries
  • Use workflow and alerts to reduce cycle time associated with reviews/approvals

Measuring Performance – Capturing the data required to measure project performance, and make the appropriate “course corrections”.

  • Measurements are a by-product of the project work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

I have worked with a number of clients that have seen some incremental improvements in their project environment using SharePoint, but they have not realized tangible improvements in their project delivery outcomes. I will generally find common themes / problems in situations where SharePoint has not enabled more consistent and effective application of project management of best practices, and improved project results. These are all pitfalls that can be avoided with a well planned and executed SharePoint implementation to upgrade your project environment.

7 Pitfalls to Avoid

1. Do Not Move Beyond Document Management – Most teams start with using SharePoint to store project artifacts. In most cases this represents a technology related improvement (from share drives to SharePoint), but the tangible benefit of this function is limited to making it easier to find documents with a better search engine. I encourage teams to launch the new project sites with more than document libraries right out of the “starting gate”. Making the leap to using SharePoint as more than a document repository after the initial launch of the new project site always seems to require more focus and effort to achieve successful adoption of the new processes.

2. What Best Practices? – Many teams launch the new project site, and then start to think about what they could use it for. It is best to identify the core project processes and best practices that you want to improve through the implementation of SharePoint in your project office before the launch of the new project site. Project management best practices that are prime candidates to be incorporated in your SharePoint implementation include:

  • Organizing Project Deliverables
  • Managing Risks & Issues
  • Change Management
  • Managing Project Milestones
  • Project Status Reporting
  • Team Roles & Responsibilities
  • Project Meetings
  • Project Metrics

3. Teams Building “Their Own” – Trust me on this one, you do not want teams starting from a blank project site, and creating their own project management “best practices” on the fly. It pays huge dividends to take the time up-front to create a “template” for the project site. This template is used to create each new project site. The template ensures that the teams have a common “starting point” for implementing project related process. The project template also ensures that project metrics and reports are created in a consistent manner, and enables more effective “roll-up” of information to the project portfolio level. The following are examples of what should be included in the definition of the project site template:

  • Definition of metadata (e.g., definition of project status – Red, Yellow, Green)
  • Site permissions, using predefined project roles/groups
  • Libraries for project deliverables, organized in a consistent manner
  • Lists for managing key project information (roles & responsibilities, risks & issues, change requests)
  • Predefined workflows for specific processes that involve reviews / approvals (e.g., change control)
  • Views for communicating information to stakeholders in a consistent manner

4. Integration Gaps – Working at clients that do not have SharePoint fully integrated in with their overall infrastructure makes you understand the impact integration can have on your SharePoint implementation. For example, when clients do not have “single sign-on”, your team quickly gets annoyed with logging onto SharePoint each time they access the project team site. Pretty soon you find they access the site less frequently, and do not view it as a core element of completing project work. Another example of integration of SharePoint within your overall infrastructure is email. When your infrastructure does not include Outlook 2010, the project team cannot take advantage of the integration to fully automate workflows (e.g., approval of project changes) or manage team meetings (e.g., meeting workspaces).

5. Collaboration is Not a “Team” Thing – If the project team sees the value in the collaboration tools and processes, they will take ownership for updating and maintaining the project site. The value of collaboration is significantly diminished if the project manager is the only person providing updates to the project site.
The collaboration tool must represent the single source for current project information. As the project manager, you need to make sure team members use the tool in this manner (e.g., discourage people from maintaining work in progress offline on their own laptop).

6. Over Engineering the Project Sites – Many clients have a tendency to over engineer the project sites. Over engineering presents itself as elaborate structures for document libraries, capturing too much information to perform processes, or creating complex workflows for reviews and approvals. Ultimately adding all of these “bells and whistles” makes it harder for project teams to understand and utilize the site, and usually does not do anything in terms of driving better project results. The project sites should be set-up in a manner that requires very limited training to on-board new team members. In addition, avoid creating document libraries with many levels of folders – use metadata to organize the documents.

7. Projects End, Make Sure Your Artifacts Do Not – With a little luck, your projects have a beginning and an end. Decisions need to be made at the end of the project in terms of what happens to the project site. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts. Organizations that do not purposefully store and utilize project archives generally make minimal progress in the area of continuous improvement.

A Proven SharePoint Implementation Approach for your Project Office

The standard approach related to implementing a collaboration platform to upgrade your project environment includes the following:

  • Identify (or confirm) the “critical few” best practices that should be emphasized and integrated into the collaboration platform.
  • Establish some standards / guidelines that would be used by each of the teams (and a place where these standards are accessible). Some examples include:

    When to create project site

    What are the standard elements of the project site

    What meta-data is important for standard reporting or site organization

    Create templates for key lists and libraries (risks/issues, change requests, status reports document libraries)

  • Depending on the experience of your project team, you may need to provide training for the team on SharePoint. At a minimum you need to get your up to speed on the specifics associated with the implementation of SharePoint within your project environment.
  • Get started. Don’t wait until everything is perfect before you launch your new project environment. You will never get complete consensus on the standards/guidelines, and there is an opportunity cost associated with delaying the launch of your new project environment.
  • Establish processes to identify and capture best practices in the context of your new project environment. As these ideas are incorporated into the standard best practices they will be reflected as tangible continuous improvements.

 

 

 

Video – Using SharePoint to Improve Project Delivery

On June 7, 2011, I participated in the SouthEast Productivity Enterprise Enablement Virtual Conference hosted by Mike Gannotti from Microsoft. The conference was a one day event with over 30 presentations on-line using Microsoft Lync.

The first part of the video is Mike Gannotti with the introduction to my presentation. My presentation starts at around 1:30 and lasts for 50 minutes. The topic for this presentation is one of the things I frequently blog about — Using SharePoint to Improve Project Delivery. The presentation provides an overview of how SharePoint helps improve your project environment, and includes a demo of applying specific project management best practices using SharePoint.