The Project and Line Manager: Final Conflict

Posted by Josh Nankivel

From the pmStudent community:

Hello Josh,

My question is regarding the relationship between project manager and line manager. Especially when it comes to project driven organization, what is the purpose of line manager. I read a book regarding this, the more I read about it the more I see the conflict and confusion between project manger and line manger. Do you have a chance to explain how line and project managers work together effectively.

Thanks.

Get out your light sabers

282930678 7f64fdcc2b The Project and Line Manager: Final Conflict
by Thunderchild tm via Flickr (Creative Commons-licensed content for commercial use)

In a matrix organization, you are going to have at least two types of managers. Line (or functional) Managers and Project Managers. There are different types of organizational structures along a spectrum which companies can be highly projectized or highly functional. Along this continuum the project manager role and line manager roles change. Their roles are also highly dependent on the organizational culture. Read more »

Communicating Project Scope

Posted by Brad Egeland

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

The Scope Document

Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important. Read more »

Project Management Templates

Posted by Brad Egeland

Over the past several couple of weeks I’ve discussed many project management-related templates and documents that are commonly used. And along the way over the past 10 months there have been a few other templates and documents discussed.

In an attempt to provide a one-stop document to link to all those templates and documents discussed so far, I’m going to pull them all into this article as a list with available links. Hopefully, having the accumulated list available in one place will be helpful to our readers.

Again, not all of these will be links to templates…some will merely be links to documents that have been discussed in greater detail in previous articles.

Summary

As discussed in most of these articles, if having the actual template in a Word doc format would be helpful, just let me know and I’ll be happy to send it to you if I have it. In some cases, I may be able to send you an actual example document from a real project allowing you to better see how I’ve populated some of the information with meaningful data. I’ll revise and republish this article as I make more templates and documents on these and similar topics available that I think would be useful to our readers.

Creating a Document Control Plan for Your Project

Posted by Brad Egeland

Most of the projects I’ve run in recent years have involved just a few documents and all control of those documents can be handled through the use of the following:

  • A version table at the beginning of the document
  • A standardized file naming structure
  • A document status section on the status report
  • Formal signoff sheets for delivery team and customer

However, if your project is extremely large, looks like a large program rather than a project, or has a government agency or institution as it’s customer, it may be prudent and even necessary to use a formal document control plan to outline the process you – the project manager – will use to manage the various documents that will be created, reviewed, and approved during the course of the engagement. Only do this if it’s beneficial for the project and for both teams as I certainly don’t believe in doing extra work just for the sake of doing extra work. But a solid document control plan can be beneficial in the right situation.

I don’t have one of my own, so I’m including Carl Pritchard’s description of a document control plan as laid out in his book “The Project Management Communications Toolkit.” If it’s something your project needs, then I think you’ll find this information very useful.

The Document Control Plan

Purpose

The document control plan is an outline or guide on how physical or virtual documents will be managed throughout the life of the project. It provides a road map for tracking documents and for adding, archiving, and removing new documentation from the process.

Application

The document control plan is used whenever sufficient documentation exists to warrant a specific process for the control, sequencing, and maintenance of documentation through multiple channels. It is initiated to ensure that those involved with the project share an understanding of how information in the project will be managed and who will have access to which documentation at which point in time. It is used during the project as both affirmation of the process and as the means to educate others on the process application.

Content

A document control plan may consist of little more than an index of available documentation and its intended locations, or, in more ornate applications, it may consist of a matrix of documents and their owners, locations, update schedules, circulation lists, archival locations, and destruction dates. Some of the common issues with document control are evident. Depending on how the document is crafted, it may be necessary to update the document control document any time a document is updated. Such would be the case with the “Location” column, for example, because each document is called out in its most current version. By contrast, if a wildcard location is called out (in, say, an “Archive” column), then the document control plan may go for a more extended period without an update. Similarly, if team and organizational titles are identified, rather than names, the need for frequent updates may be lessened significantly.

Approaches

The document control plan can be approached in a variety of ways, including straight narrative or the tabular format shown here. There are normally extensive cross-references to other documentation and to storage repositories within the organization. Document control frequently incorporates the protocols for version control of documentation as well. This may be as simple as incrementally renaming files as new iterations are created (e.g., Document01, Document02, Document03) or may involve protocols that address authorship, ownership, or the responsible party for the latest iterations (e.g., Document01.Bob03, Document01.Bob03-Martin01). The rationale for and description of the approach(es) should be clearly delineated in the narrative associated with the document control plan.

Considerations

While project managers may be tempted to arbitrarily set the archive and destruction dates for aging documents, the legal aspects of document maintenance need to be considered. Project organizations have legal responsibilities to their clients and to their governments and regulators to maintain certain documents. The laws regarding document retention vary from region to region and agency to agency. Before establishing (and implementing) document destruction protocols, legal counsel should be sought.

Project Go – No-Go Decisions – Part 4

Posted by Brad Egeland

In this segment, we’ll look at the non-financial criteria for selecting projects to proceed with. Basically, here we’re looking at weighted factor scoring to identify whether a project should move forward. The info in this article comes mainly from Gary Heerkens’ book “Project Management.”

Using Non-Financial Criteria for Project Selection

Financial models express costs and benefits in dollars and cents. As mentioned earlier, estimating certain kinds of benefits in financial terms can be quite difficult or uncomfortable. In other situations, accurate data may be obtainable, but only by conducting expensive tests, studies, or surveys. Whenever the process of getting good financial data is difficult, expensive, or time-consuming, using a weighted factor scoring model (decision matrix) may be a reasonable option for selecting the best alternative solution.

The figure below shows a decision matrix constructed to determine the preferred model of automobile. We’ve identified six attributes that are meaningful to us: cost, comfort, style, handling, reliability, and resale. We then weight each attribute by assessing a relative importance to it. The weights must total 1.

decision matrix Project Go   No Go Decisions   Part 4

To use a decision matrix, you need to establish a scale for rating each alternative for each attribute. (The example shown uses a five-point rating scale.) You must define the scale so that everyone has a common understanding of what each rating number—0, 1, 2, 3, 4, 5—represents. Once you’ve established the relative weighting and the rating scale, it’s merely a question of filling in the blanks to determine the best alternative. In our example, using six weighted attributes and a five-point scale, the Lincoln Town Car was determined to be the best alternative.

Use of a weighted factor scoring model offers several advantages:

  • It allows for using multiple criteria, including financial data. The attributes you select could include any combination of the four financial metrics presented in this chapter.
  • It is easy to construct and to interpret.
  • It allows for management input. Management can determine the appropriate attributes and the relative weighting. In fact, involving management in constructing the matrix may streamline the project approval process.
  • It is well suited to what-if studies and sensitivity analysis. Trade-offs between criteria are readily observable.

There are also some disadvantages:

  • The process relies almost entirely upon subjective measure, thus opening it up to questions of bias, halo effects, and reliance on opinion or judgment.
  • The result obtained is only a measure of relative attractiveness. There is no absolute verification that any of the alternatives identified is a justifiable investment from a business perspective.
  • All attributes are assumed to be independent; there are no allowances made for interdependencies between or among factors.