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

Lines of Communications

I created this figure for a survey about the routes of information needs within an engineering group.

Blogspot is not making this easy. 

You may have to right-click on the figure and save the file to your desktop to view it properly. 

Two Steps toward Making Stakeholder Management Manageable

Two Steps toward Making Stakeholder Management Manageable

The materials I've found about Stakeholder Analysis have not explained much more than the PMBOK Guide explains. What grids other than the Power/Interest grid tell me remains a mystery.

However, I have found two hints that simplify the whole Stakeholder Identification (and Analysis) process.

Divide Stakeholder Analysis 

PMBOK 4 describes Stakeholder Analysis as a single Tool/Technique. I would split off the elicitation of information as a separate technique and call it Stakeholder Survey.

Use a form as you visit around the office eliciting detailed stakeholder information. Transfer that information to the Stakeholder Register at the end of the day. If you put the register on a server and can access it register through Wi-Fi, you can save on data entry time.

Fill in what you can before bothering stakeholders. Then verify that information and elicit the rest, as much as you can, face-to-face. For what remains, you can use a questionnaire.

Simplify through Progressive Elaboration 

Consider an analog in Risk Management: First, you use Qualitative Analysis to identify the key risks. Then you use Quantitative methods to analyze only the key risks.

Now, take these lessons from that model:

• You don't need to perform full analyses for all stakeholders.
• You need only a small subset of the information to start.
• Decide what information you need in order to identify Key Stakeholders.
• Use the Power/Interest grid to identify Key Stakeholders.
• Collect further information and perform further analysis only on the Key Stakeholders.

Increase the degree of Stakeholder Analysis through progressive elaboration.

1. First iteration: Key Stakeholders
2. High Power/Low Interest stakeholders
3. High Interest/Low Power stakeholders
4. Low Interest/Low Power stakeholders

Remember, subsequent iterations should require less information and analysis.

This may be as much a delaying tactic as a simplification, which is what I really wanted. However, reducing, breaking up, and delaying the work relieves some of the stress of a potentially overwhelming process.

3 Factors in Risk Management: Probability, Impact, and Velocity

Risk Score

Qualitative and Quantitative Analyses in Project Risk Management both take into account Probability (P) and Impact (I). A Risk Score is the product of the two.
Qualitative Analyses use subjective estimates of probability and impact as a screening process that categorizes risks for management, monitoring, or ignoring. Risks placed in the management category go on to Quantitative Analysis and Risk Response Planning.

What about Urgency?

A third value should be considered: Velocity (V), which is the inverse of the time-to-impact.
Seldom can we deal with all risks at once. The value of considering Velocity lies in prioritizing further effort so you have enough time to respond to urgent risks. We would not consider Velocity when assigning risks to the three categories because we want to deal with the important things, not the urgent things. (Consider Pareto's 80/20 rule.)
If Probability times Impact describes an area, then to be consistent, we would add Velocity as a third dimension. That is,
Priority Score = Priority x Impact x Velocity

Another View of the Priority Score

Priority times Impact has another label, which is Expected Monetary Value (EMV). EMV is often used by itself for guiding decisions. If we express the Priority Score as
Priority Score = EMV x Velocity
then we give EMV a weight equal to the weight of Velocity.
The reason we would not consider the Velocity by itself goes back to the principle about the cost of rework. The later you deal with a problem, the more it costs because you have to repeat and fix work that came before. The previous effort becomes wasted, costs rise, schedule lags, and you have to use extra resources to get back on schedule.
Similarly, the longer you wait to deal with a risk, the more rework you have to do. Therefore, we need to factor both Velocity and EMV into prioritizing work: Velocity to deal with urgent risks, and EMV to control costs.

A New Step: Priority Analysis (when needed)

I recommend inserting a new step into Risk Management when there are risks with high velocity and you have to prioritize which risks to deal with first:

1. Qualitative Analysis with Risk Score = estimated Priority x estimated Impact
2. Priority Analysis with Priority Score = EMV x Velocity = Priority x Impact x Velocity
3. Quantitative Analysis with Risk Score plus other factors such as Velocity and Cost Effectiveness

I bring up Cost Effectiveness because you want to ensure that you don't spend $150 to prevent a risk whose EMV is only $100.

Reference

Hall, Harry, PMP, PMI-RMP. 30 Quick Risk Evaluation Tips. PM South. http://www.pmsouth.com/2015/07/18/30-tips/. Accessed 21 July 2015.

The Black Hole of the Agile World: Systems Thinking

Agile fanatics (excuse me: practitioners) love to do things in tiny increments.

That's OK for products where bite-sized deliveries have value, but it's fantasyland for many real-world projects.

Take, for example, the design of a new car. Sure, you can break the car into systems -- chassis, body, safety package, motor, and so on. Waterfall does that, too, but let's consider the airflow over the body. The airflow is affected by the whole assembly. Every part affects the whole. You can't just design a fender in isolation and say, "Looky, looky, I've delivered value!" No, you've delivered an irrelevant piece of scrap.

In any course on Business Analysis, the importance of a unit on Systems Thinking cannot be overemphasized because the Agile world has completely forgotten its value. 

Before the 1990's, there was a role called Systems Engineer.

That title is still around, but the job is not. At least, the job has become a rare grain of wheat a vast field of tares.

A Systems Engineer had many skills of a project manager, a BA, a Systems Thinker, and a cross-disciplinary engineer, all rolled into one.

Along come companies such as Microsoft and Cisco, dropping the qualifying word from titles such as Network Systems Engineer, Software Systems Engineer, and Server Systems Engineer. Suddenly, every engineer, analyst, and administrator is a Systems Engineer. I wish I had a paycheck for every time a recruiter has contacted me with a so-called Systems Engineer job that turned out to be for an IT admin or a software coder.

True Systems Engineering jobs have become needles in a field of haystacks, and systems thinking has almost been forgotten.

Thousands of Systems Engineers lost their jobs due to decimation of the US Defense sector in 2009. (I proud of myself for not pointing out the predictable political element of that.) They still find three strikes against them:

1. Transitioning to a different job category such as Project Management or Business Analysis
2. Getting a foot in the door of a different industry (other than fast food)
3. Living in a job market where all the growth is in part-time service jobs and has gone to low-skilled workers

Hiring managers would do well to consider bringing in experienced cross-disciplinary, systems thinkers. It would not take much training to bring them up to speed in new roles such as PM or BA.

Have you ever thought of a project as a system of people, or a product as a system of technologies? Systems Engineers do that instinctively, and such integrated systems thinking could prevent a lot of headaches for maturing companies.

Now, if you'll pardon me; I need to clean up a spill in aisle five.

Models versus Prototypes

What is the difference between models and prototypes?

Some people are confusing prototypes with models. Most of the examples given in other comments are engineering models (and they are valuable). A prototype is one type of model.

1. Before prototypes, you have engineering models. For example, a wireframe diagram just sits there. It's not a prototype, but it's still valuable. On the other hand, you might have a program with a generic GUI. It might be fully functional, but without the semi-final GUI, it's still not a prototype.

2. A prototype is the first (proto-) thing of its class (-type). Prototypes would include the Beta version of a software product or a widget built in a shop.

3. After the prototype, you have the production model. That's the model you sell in the store, the one you send out samples of, or the one that comes off the assembly line.

Off my soapbox and on to the questions:

1) Does prototyping have to be studied by external institution?

That depends on the product. Suppose you work in IT and designed a SharePoint site for the Engineering department. You will want Engineering to see models and then the prototype in order to identify the refinements that will take your product from "Gets the job done" to "Delights the customer." If your customers are other companies: Yes, you want it to be reviewed by them. And if you are subject to regulation by government agencies and licensing authorities, it's far less expensive to get their approval early than to get it later.

2) What information can we get from prototyping? Does the information we get show us the quality or preference or anything else?

Quality means, "how well the product meets the needs." If showing the prototype to the customer helps ensure that it meets the customer's needs and preferences, then the feedback helps to ensure quality.

For example, before converting Office from drop-down menus to ribbon bars, Microsoft probably let hundreds of users play with it. They would have found out preferences for how many icons to fit in a frame, which functions to place in the ribbon, which functions that were now hidden people would have to go hunting for, and how much they'd have to spend on marketing to convince people to accept the transition.

From a systems perspective, when Microsoft converted Office from the old file types (.doc, .xls, .ppt) to the new formats (.docx, .xlsx, .pptx), they used prototypes to investigate compatibility between programs.

 

For example, could you still import a section of an Excel spreadsheet into PowerPoint? Could you still save a Word document to Open Document Format or RTF files? Will Word and Excel compete for the same memory space and slow down or even crash the computer? Will the new version of MS Access have a reduced startup time?

 

Even after that, Microsoft still puts Beta versions in the hands of thousands of users to find the problems nobody thought to test for.

 

You can't answer such questions with confidence until you build working prototypes to test and experiment with.