Name Your Files for the Readers — If You Care

Filenames — A Trivial Time-waster that Adds Up

How do you react when you see a filename like 500002p.pdf? 

Is this a file that you want to open? 

Do you think that the author of the file cares whether you open it? 

This one's a little better, but not much:  BBP3.0FactSheetFINAL.pdf.

What Do You Want to Know?

When I look at a filename, the first thing I want to know is what it is. After that, I want version information. 

Some people put their initials first.  In a team folder, the listing will group the Jim files, then the Joe files, then the John files, and so on.  (And then there's Jack who sometimes uses JB and sometimes JEB.)

Then you have to search up and down the screen to find all the versions of the same file.  The larger the team and the longer the project goes on, the more this wastes time and leads to mistakenly working with outdated versions.

A government website has a folder of presentation files in this format:  

2014_05_15-Draper-6th-AGNC-Welby-final.pdf

Placing the date first is redundant because you could always sort by date in the file explorer view.  Apparently, the Welby made the presentation and worked for Draper, and the topic was some cryptic initialism.  Now, how are we supposed to find presentations on risk management among 74 files with names like that?  Do you have an hour to spend opening all those files?  

There's another human element. When a filename starts with initials or has a serial number instead of a name, my eye says, "random, meaningless letters." Then my amygdala says, "look away!" 

Sometimes my amygdala wins, and sometimes my cerebral cortex wins. That contest creates stress. wastes time, and sometimes blocks communication completely. 

If you have a Content Management System (CMS) or Configuration Management System (also CMS) such as SharePoint, you have ways around this.  You can add fields for author, date, version, and subject.  

Often, however, we are stuck with filenames.  Even if your team has a CMS, you will still sometimes wish to download a file to your own drive.  If you don't remember what's in that cryptically named file three months from now, will you even bother to open it?

Since I read from left to right, and since an alphabetical sort proceeds from left to right, I recommend the following name format:

topic - [rev or yyyy-mm-dd [24-hour time if needed] ] - initials

example

meeting notes, team, 2015-08-01, rev A, rw.docx

Filenames should be in plain English. 

When I download files, I hate seeing files with names like BB097834.pdf.  I should not have to download and open a file in order to determine whether I want to download and open it. 

And by the way, who is JS, and does he or she even work here any more?  Does it feel professionalI to use your initials?  How professional will it seem to others, two years after you've taken that big promotion at another company and nobody here remembers whom JS was? Spell things out.

Some content management systems assign garbage names automatically.  We cannot do anything about that.  And some authors write only for their own vanity.  They do not care whether anybody reads what they wrote.  Try not to obsess over it; I've already done that for you.

A filename is like a headline or the title of an opus.  

A good author or editor knows that Job One is attracting an audience and, therefore, puts a lot of effort into creating a meaningful, eye-catching filename. Which would the classical music lover in your life rather listen to?

• PITop066.mp3

or

• Sleeping Beauty, Peter Ilyich Tchaikovsky, opus 66.mp3

It's about more than efficiency. It's about consideration.

Copyright 2015 Richard Wheeler

Communicating the Organization's Direction: The Missing Ingredient

The average worker could not tell you the vision of the employer.

To some degree, the average worker can perform just fine without knowing the mission and goals of the business. However, knowing the purpose of the work can guide decisions made in the course of the work. Perhaps more importantly, having a known, defined purpose can motivate the worker by providing a roadmap to the work's contribution. It provides a personal connection to the work and to the company. This, in turn, improves performance and retention.

Leadership can improve overall performance by communicating the vision, mission, and goals of the business, as well as the specific objectives of each project. (To cut down on wordiness, I'm going to combine all of those messages and call them the "direction" of the business.)

This topic could take up a whole book, but I will address a portion that I think leaders tend to forget. The specific methods and tools used will vary during the lifecycle of a project. For that reason, I would recommend organizing a more complete description of the topic around process groups or project phases:

• Project selection
• Project initiation
• Project planning
• Project execution
• Project monitoring and control
• Project closure

Defining the direction is part of creating the business plan. Any responsible business owner will create most of those materials and update them regularly. From there, communicating the direction requires breaking each section into a PowerPoint presentation, asking lower-level leadership to give it visibility, putting it to work in the organization, and setting up systems of accountability.

Businesses commonly forget to ensure that the elements of the business direction flow down to projects. Leaders present and promote the direction, but they also need to communicate it through actions that create the processes and provide the tools for carrying out the direction and controlling its implementation.

Just as the business needs to continuously review and refine the direction, the projects need to ensure alignment with the business direction. For example, many project managers set the contract as the highest level of requirements. However, many decisions made within a project depend on the business direction.

Leadership can take one step to communicate business direction by empowering Project Scope Management. They can do this by making available a good Requirements Management System (a tool such as DOORS or CORE). The project managers should then include the business direction's documentation as the top level of each project's requirements. During the project lifecycle, the project can ensure that decisions support the business direction and all requirements trace to the business direction.

Many leaders focus on communicating business direction through presentation. However, they must also communicate it through action. Obviously, actions include specific soft-skill behaviors such as demonstrating the importance of meetings by prompt attendance. But they must invest in resources that empower their teams to use direction as a tool and to use it as the measuring stick of performance.

Make Lessons Learned a Part of Your Culture

An organization with process maturity will close the loop on Lessons Learned.

By closing the loop, I mean that the organization will ensure the capture, distribution, and institutionalization of the lessons taught by the school of hard knocks.

While the Project Manager should identify and collect Lessons Learned, Quality Assurance should categorize and preserve them.  QA should take further steps to communicate the lessons.

First, leaving it to everybody to go searching the LL database does not work.  Like that will ever happen! Ha!

Instead, QA should sort the LLs by function and subject and distribute the information to affected functional managers across the organization.  This ensures that, for example, the Integration Engineers in different programs and at different locations receive the expensively acquired knowledge.  If the functional managers fail to communicate the lessons to their people, upper management should give QA the authority to do so.

Second, QA should incorporate applicable improvements to the Organizational Process Assets.  This way, QA does not merely deposit critical knowledge into the Tribal Knowledge Bank, but actually institutionalizes it.  This introduces accountability when QA audits process compliance.  It also allows the lesson to be moved to a section of the database that lists rationales for historical purposes.  Not every Lesson Learned needs to be researched for normal operations.

Note that this involves Change Control at both the project level and at the organizational level.

As an example, engineers delivered documents to a customer without the necessary review and approval of the Chief Engineer.  The incident led to rework and incorrect customer expectations.

Tribal knowledge had established a channel that would have ensured proper review before release.  However, new employees did not know it, and management had nothing in writing that allowed them to discipline experienced employees who knew better.

Engineering stepped in where corporate management had left a gap.  They instituted processes for document review and approval and for an engineering communications manager to coordinate release of documents to clients.

Thus, an incident led to a Lesson Learned.  The Lesson Learned led to policy and procedural changes.  The new practice became part of the formal procedures and did not get lost in a database that ever researched.

Copyright 2013, Richard Wheeler -- Permission granted for non-profit or personal use with a link to this post.

IT Metrics and Productivity Institute (ITMPI) Premium membership gives members free access to 400 PDU-accredited webinar recordings and waives the PDU processing fees. The library is growing at about 100 webinars per year. Check it out: http://mbsy.co/dPHm?s=e

The Lobbyist on the Project Management Team

You are the project manager in an aircraft manufacturing company developing a new range of supersonic fighter planes. Since government approval and involvement are essential, you hire a lobbying firm to get government support to prevent unnecessary changes in your project. Which process is this an example of? (Source unknown)

While aircraft manufacturers conduct some research into designs and materials that they can incorporate into new aircraft, governments usually sponsor development of fighter jets.

 

Scope creep happens in almost all defense projects.

 

For example: 

• The Defense Department wants the aircraft to provide certain capabilities for the Air Force.
• Then the Navy wants compromises in the design so the jets can take off from carriers.
• The Army and Marines add their particular use cases.
• Allies want introperability with their systems.
• Later, one politician wants to cut costs,
• another wants the aircraft to use inadequate landing gear designed by the manufacturer in his home town,
• and over 600 politicians and thousands of bureacrats want to influence the project.
• Meanwhile, competitors and the nation's adversaries develop new technologies to which the designers must respond.
• And one of the political parties, along with the press, begin mocking your aircraft by calling it an Imperial Tie Fighter.

If you let it, the politics will multiply the cost twentyfold, drag out the schedule an extra 15 years, and make your company a laughingstock. By the time of the first production run, the aircraft will already be obsolete.

 

The same sort of changes can happen in any project. One way to control the risk of scope change is to refuse to make changes, but too little flexibility can create customer dissatifaction and cost you future business.

 

For a better way to reduce the risk of scope creep, maintain close personal relationships with the stakeholders, keep them informed of the costs of changes, and negotiate agreements that best serve the business case.

 

The PM cannot always do this, so the company hires a lobbyist with exceptional people skills and knowledge of the bureacratic systems. The lobbyist uses various methods to convince the politicians and bureaucrats to resist tinkering with the project requirements.

 

In process terms, hiring a lobbyist does not proceed from the Project Communications Management processes. Lobbying does not contribute directly to producing the product or providing a service. A first pass through the Identify Stakeholders and Plan Communications processes would assume everything goes as planned and would focus on required reporting and coordination. The lobbyist's job goes far beyond that.

 

If the team identifies scope creep as a risk, they make a note to consider it later when they follow the Identify Risks process. They would, at that time, add recruiting a lobbyist to the Risk Management Plan portion of the integrated Project Management Plan.

 

Don't forget that, as a member of the project team, the lobbyist becomes a stakeholder. For example, the team must add the lobbyist's tasks to the WBS and estimated costs during the next iteration of project planning. They must also consider the lobbyist's information needs during the next iteration of the Project Communications Management processes.