Why Traceability (by itself) Is Worthless

Performing traceability of delivered functionality to requirements without tying them back to Business Objectives is in my opinion an exercise in futility. To anyone engaged in this exercise, I ask “So What?”

At first blush this might seem like an extreme position to take. The benefits of requirements traceability seem readily obvious whether or not they are tied back to Business Objectives. You can determine what requirements were implemented, when they were implemented, what still needs to be done and so on. All of these are good things in and of themselves.

Do You Need Business Objectives For Software Requirements Traceability?

By way of answer, imagine that you are writing requirements for an Experiment Management system. Consider the following scenario.

The first set deals with setting up the experiment. The other set deals with analyzing the results of the experiment.

One of them is responsible for the team that defines and sets up the experiments. The other manager leads the team that analyzes the results of the experiments.

Each set had a total of 10 requirements each. The users prioritized their requirements and each team came back with 4 “critical” and 6 “nice to have requirements”. Assume that all the “Critical” requirements are equally important and deliver approximately the same amount of functionality each to the final delivered product.

They satisfied all of the “nice to have” requirements of both sets. All 4 critical requirements of the experiment analysis requirements were satisfied, but only one of the critical requirements of the experiment set up requirements.

Business Objectives Are Your Yardstick For Success

Simple traceability that did not tie back to Business Objectives would show something along the following lines:

By any yardstick it looks like a spectacularly successful release.

But consider for a moment if the Business Objective for the release has been defined as “reduce the amount of time taken to perform experiment set up by 90% so that the company can increase the probability of successful new product creation by increasing the number of experiments that can be set up by our team of scientists.” The company came up with this objective because it is far easier for them to hire analysts than find skilled scientists who can dream up new experiments that will result in new products.

If we were to apply this knowledge to traceability and coverage of requirements, a very different picture of the success of the release emerges.

All else remaining the same, from a Business Objective stand point, we have about 25% coverage of what is really important to the company for this release. So, this was a pretty dismal release though the raw statistics that do not tie back to Business Objectives seem to indicate otherwise.

At the end of the day, companies build software that advance their prospects and help them achieve specific business goals. As requirements professionals, we need to tie back the outcomes to the Business Objectives. So, if we are not tracing requirements back to the Business Objectives, we are generating data that may or may not be useful or relevant in the grander scheme of things.

There is definitely some virtue in generating data for its own sake. This would be the case in doing all the hard work to trace requirements to specific functionality that has been delivered. But not taking the final step and tracing it back to Business Objectives misses the whole point of the exercise. We are guilty of generating data without giving it the proper context that Business Objectives provide.

So the next time, someone tells you they are tracing delivered functionality back to the requirements, ask them if they are tying them back to Business Objectives. If the answer is no, ask them “So What?” I would.

Controlling Changing Software Requirements

The CCB (Change Control Board). It is their responsibility to oversee and approve any proposed changes to your software project. They're officially in charge of moving the cheese around - or approving completely new cheese.

Once they get to work, your nice, safe plate of Pepper Jack could morph overnight into something rich and strange, like English Farm Cheese with Dried Currants.

Project changes happen, but they aren't always easy to deal with. And they don't just affect Development (Nacho Cheese Doritos(tm)) or QA (Swiss Cheese).

It's critical that CCBs recognize that scope changes also affect documented requirements and the people who manage those requirements.

Scope Changes Affect Software Requirements Tasks

Changes approved by the CCB may generate requirements-related tasks, such as:

• Identify all requirements impacted by the change (requirements traceability will make this much easier)
• Update impacted requirements documentation and related models
• Manage review and approval of changes to existing requirements
• Elicit additional requirements to supplement or replace existing requirements
• Communicate all changes to impacted parties

Keep Business Analysts in The Loop

All impacts of a requested change must be identified and agreed upon so that informed decisions regarding the request can be made.

Even seemingly small or simple requests can easily become big changes when all of the related activities are considered.

Be aware, actively participate in controlling change on your project, and when your CCB hands you a wedge of Vieux-Boulogne (the world's smelliest cheese), you won't even blink.

Signing Out from INCOSE 2008

Well, I hate to say it, but my week here at INCOSE 2008 has come to an end. And though I must say goodbye to my INCOSE friends, I'm not headed home quite yet - first I will enjoy a few days in Amsterdam, just up the road from Utrecht.


A few final comments from this side of the pond (some of these are purposefully non-INCOSE related to keep it interesting!):

• After hours of listening to talks about process, I have to say - systems engineering processes are heavy! There are images dancing in my head of things like a project plan circle diagram that even in a 3x3 foot printout, you have to squint to read the tasks. Or there are the matrices that don't even come close to fitting on a page, yet they try to squeeze them in for demonstration of a concept.
• I spoke with some systems engineers who, when I explained what Seilevel does, said things like "Really? Requirements as a job?" or "You have a business around that?" or "I never thought of them as a separate thing, they were just some other task on my project that maybe got done." or my favorite "Why are you at a systems engineering conference then?"
• It's a small world. In a city of more than a million, today I ran into a fellow INCOSE member from San Antonio, TX on my way back from the Rijksmuseum.
• Most all of the presenters like to use words on slides! Seriously, I almost think it must have been in the presentation requirements - "Must have wordy slides". Perhaps I can suggest Beyond Bullet Points.
• I enjoyed reconnecting with my friends from what I like to call "Seilevel Europe", the HOOD Group (and mind you, they would and should probably call us "HOOD Group USA"). We have very similar companies, with similar methodologies, in different parts of the world. If you haven't heard of them, I encourage you to take a look at their work.
• Sadly, Holland just lost in the quarter finals of the Euro 2008. I say sadly because I've actually become quite fond of watching the "Oranje" games (or maybe just the crowds hanging outside of bars).
• I once again was reminded that so many Americans have a tendancy to focus on just us. This is by no means a generalization though. I personally like to intermix with those from other countries, though I'm also quite guilty of speaking American and little else. Anyway, it was frustrating to listen to talks from Americans who would only quote American statistics, or American events, or American disasters. My European friends were quick to point it out for me "Oh another American talk!". Thankfully some of the talks were very different than that though, making me much more proud.
• We should do more peer reviews, but not for the obvious reasons. A systems engineering organization requires team members to be on peer review boards, not so much for improving the quality of the deliverables, but more importantly, to expose the engineers to more projects and ideas that they can then apply to their own projects. Brilliant, I say!
• The field of systems engineering has many many many outstanding success stories, ranging from the Airbus 380 to the ProRail system of the Netherlands. There are lots of great lessons to be learned here that can be applied to much simpler projects. But really, how cool would it be to build a network of thousands of kilometers of rail or to put a new airplane in the air?

Anyway, in a few days, I will return home with many fond memories of the Netherlands and INCOSE 2008.

INCOSE 2008 - Can You Build an Airplane with an Agile Approach?

With all of the buzz about Agile, I have to mention that here at INCOSE 2008, I did not hear a single mention of it (except when I asked about it directly!). Actually, that’s not true, at one point I was excited to see a speaker’s slides which referenced applying agile processes as a step in a project. Then he spoke to the slide and I started to suspect he meant agile in the pure definition of the word, to move quickly. At the end, someone asked him the specific question as to whether he meant the agile software methodology and he clarified that he did not. So I left the conference wondering - with all the discussions about processes at a conference like this, why are they not ever speaking about agile?

Airplanes Are Not Software Requirements

My first guess - this probably relates to some of the core differences between systems and software engineering. I am going to over simplify this and just say that it is about scale. Systems projects are just a superset of software and hardware projects, integrating and deploying some combination of these. The teams of people deploying systems projects are quite large. And many of the projects discussed here are for government or regulated systems where specification and traceability is necessary. I could see how subsets of systems projects could in fact be developed using agile (pure software components), but I’m not convinced that an entire end-to-end project can. To put this in context, imagine you are building an airplane - a very commonly referenced type of systems engineering projects. Can you see this working using agile?

All skeptism aside, I do think that iterative development most certainly could work well on systems projects, and most people here would not argue that. In fact, I would love it if we could find examples of agile working on systems projects, because the number one feeling I get at systems engineering conferences is a craving for lighter processes.

I decided to do a little research outside the conference walls, and low-and-behold, I found a great article on this exact topic – “Toward Agile Systems Engineering Processes” by Dr. Richard Turner of the Systems and Software Consortium. The article is very well laid out, and I highly recommend reading it. He defines what agile is and what he believes the issue why most systems engineering projects are not agile. For example, he suggests that executives and program managers tend to believe that the teams involved have perfect knowledge about systems we are building, so we can plan them out in advance and work to a perfect execution against a perfect schedule.

Agile Can Work With Complex Systems

He talks to how to the agile concepts can work in systems projects. Here are a few examples summarized from his article:

• Learning based: The traditional V-model implies a one-time trip through, implying one time to re-learn. However, perhaps the model can be re-interpreted to allow multiple iterations through it to fulfill this.
• Customer focus: Typically systems engineering processes do not support multiple interactions with the customer throughout the project (just up front to gather requirements). That said, he references a study indicating the known issues with that on systems projects. Therefore, perhaps processes should be adapted to allow for this, particularly allowing for them to help prioritize requirements throughout projects.
• Short iterations: Iterations are largely unheard of because the V-model is a one-time pass through the development lifecycle. That said, iterations of prototyping through testing could be done in systems engineering in many cases. The issue is in delivering something complete at the end of each iteration. He suggests that this is not as important to the customer in large deployments as is reducing risk, validating requirements, etc. This is a great point to rememember the airplane example! Could we have even a working part of an airplane after 2 weeks? What about even the software to run a subsystem on the aircraft?
• Team ownership: Systems engineering is very process driven, so this one is tricky. Dr. Turner puts the idea out that perhaps allowing the systems engineers to drive it instead of the process to drive them, while more uncomfortable for management, might produce more effective results.

So while he does give some suggestions to adapt systems engineering processes to be more agile, I don’t think this will qualify as purely agile. And frankly if it we tried it, I think I'd be fearful to be in the airplane! But to quote Dr. Turner directly “…other hand, agility is much more a state of mind or philosophical approach than a set of rules that have to be followed regardless of appropriateness.” Using that idea, combined with what I saw at INCOSE 2008, I can see some definite opportunities for improvements for the field systems engineering.

INCOSE 2008 - Technical Team Accountability for Requirements and Delivery

James Andary, Maria So & Barry Breindel from the NASA Goddard space center presented “Systems Engineering Technical Authority: A Path to Mission Success”. The goal behind this program they call “Technical Authority” (TA) is to give a voice to the engineers on projects. Under the previous model, project managers were the central path to communicate with upper management. Looking at a history of success, this old approach worked well on their robotic missions, but not for human space flight missions. As an example from the Challenger report, there were specific technical warnings from people that were ignored, never making it up the chain to the people who had the authority to delay a launch to investigate them.

Under a TA model, the lead systems engineer on a project still has a dotted line reporting to project managers, but ultimately they report up to the engineering director, up to the center director and finally the NASA chief engineer. This means that an engineer can take an issue to the top of the chain if they believe it’s not being addressed properly. Part of the reason for using this model is that, there is a natural conflict between engineering (who wants to build a perfect system) and program management (who wants to launch on time), and this model is supposed to help eliminate issues from this conflict. They gave an example of a battery engineer who was about to quickly escalate an issue – there had been a series of launch delays which meant some specific batteries on the flight had expired. He brought the issue to the attention at a director level and they employed the appropriate people to quickly research it to determine if it should delay the launch again.

A result of this organizational model is that the engineer now has accountability for the product – and while generally a positive thing, this will probably be hard for some people to accept. The engineer now also has responsibility for understanding and implementing both enterprise requirements and project specific requirements. I admit that when I first heard this, I thought “You mean they were not accountable before if the space mission failed for a technical reason?” I think the point is not that they were negligent, so much as they were not being heard – more of a communication failure.

With this model, there no longer should be finger pointing “the project manager didn’t listen to me” and instead a focus on everyone doing their part to have a successful launch.

One final point made - when dealing with large systems project, it is important that someone on the project has a holistic view of the project. This team is working with MIT to study how you infuse that in people. They are trying to do a few things to improve this, such as exposing engineers to more of the overall mission activities, holding focus groups to share experiences, and requiring engineers to participate on peer review panels. I think there are some great take-aways from this that we can apply to all organizations, encouraging cross-project awareness.

INCOSE 2008 - Imagine the Complex Systems for Hydrogen-Based Transportation

Tuesday's favorite talk for me was "A System-of-Systems Framework for the Future Hydrogen-Based Transportation Economy" by Michael Duffy & Debra Sandor of the National Renewable Energy Laboratory. This was an interesting talk, less because of any discussion of requirements and more because it represents a complex systems engineering challenge. Also, I just wanted to share some of the topics that are prevalent at this conference outside discussions about requirements specifically.

In 2003, Bush allocated $1.2M towards developing clean hydrogen-powered automobiles. The administration has actually followed through and by the end of the year, will have spent just about $1.2M. The work at the National Renewable Energy Lab is using this funding to research and develop technologies to support the aim, including determining how they might guide the transformation of energy sources in application.

So “conveniently”, the generalized hydrogen supply chain looks a lot like the supply chain of petroleum. First, there is what they call feedstock (natural gas, biomasss, coal, or water) which logistically must be delivered (by pipes, trucks, rails, barges) to hydrogen conversion plants (this part varies by feedstock), and then from there, the hydrogen must be distributed (by trucks, etc. to fuel stations).

However, over the next 30 years, there is an expectation that as a society will move through internal combustion engine improvements, cleaner renewable fuels, then to hybrid electric and eventually to hydrogen fuel cells. The big systems engineering challenge is in the transformation from petroleum to biofuel to hydrogen systems. There is no single solution for the future, the mix of technologies will change over time, and there will never be a "flip the switch" moment in transition. Add to this a challenge that corporations will not build hydrogen cars if there aren’t convenient fueling stations for drivers to refill. But they won’t build the stations if there aren’t cars to use them.

Ultimately, the described projects at the laboratory to solve these challenges are a long way from complete – they are currently focused on system definition, and nowhere near design and development. Though, I suppose at this early stage, they are spending more time now on requirements than anything else! Dr. Duffy's presented timeline looks like 2015-2020 for the government to be using hydrogen fleets, around 2020-2030 we will have personal vehicles powered by hydrogen, and by 2040 everyone would have one.

(*All data here is sourced from the talk at INCOSE 2008, and the actual paper should be review for references).

INCOSE 2008 – How to Deal with Vague Software Requirements

Mary Bone presented a paper “Cyclone Process: Dealing with Vague Requirements” at INCOSE 2008 in the technical track. I’m going to try to summarize her work here.

Her premise is that existing requirements models do not deal with vague requirements, but rather they specifically aim to remove any vagueness from requirements. However, she contends that sometimes you will have vague requirements, and therefore need a way to deal with them.

As an example, she spoke to a requirement that said a system must work in all countries in which a unit is deployed. Well, clearly any good requirements engineering will ask “which countries”? The issue here is that this was a military application, and the list of countries was constantly changing.

A New Model For Software Requirements

Mary proposed the cyclone model which defines requirements to a risk level that is sufficient for the stakeholders. Pictorially, the model resembles the spiral model with a 3rd dimension, risk. The phases look similar as well. There is an elicitation phase in which she encourages all requirements to be captured, with any initial risk information. During analysis, this information is reviewed and a risk assessment is done on the requirements, where a risk factor and rationale for the risk is assigned. Vague requirements are just given a higher risk factor. In particular, the higher risk requirements are re-reviewed, and during a negotiation and commitment phase, stakeholders agree on the requirement, rational, risk, and risk rationale.

I think the key take away here is that you are adding a couple attributes to the requirements to reflect the risk of each one, when the requirements cannot be written clearly. While I’m inclined to avoid excess attributes on all requirements when there is no need for them, perhaps you could just assign a default “normal” risk to all requirements, and when you have a few that are still vague, you assign a high risk to only those. The project can continue forward without requirements being fully defined.

She did not speak to this, but I see this technique being most applicable to projects with strict criteria for requirements sign-off, regulatory projects, etc. In many projects, I think it’s pretty common to move forward with some vague requirements, knowing they’ll be iterated on in a future phase. It’s almost implicit in the iterative methodology.

INCOSE 2008 – Systems Engineering Railroads - So Many Requirements Stakeholders

The opening talk on Monday at INCOSE 2008, “Crossing Borders by Applying Systems Engineering”, was by Bert Klerk, the CEO of ProRail, who runs the railway system of the Netherlands. Behind Japan and Switzerland, this country is 3rd in the list of most densely used railroad networks. They have 6500 km of track and because they are a land of much water, 4500 bridges to cross. This is clearly a large system which has had great success from applying systems engineering principles.

This is not the first time I’ve heard a talk about a project for Europe’s rail systems. I find it to be a very interesting topic, and though I have never worked on a railway project, I can see the challenges so clearly. This talk highlighted an example of a track to be laid that in particular had to cross a small river. They put out bids to contractors to see who could most cleverly navigate this river while staying under budget; and the winner’s solution was implemented. But the point here is systems engineering on this scale involves hundreds of stakeholders. When dealing with these large scale systems – you cannot just think about the users at all, the scope spans way beyond that. It’s not just those people using the tracks, those operating and maintaining them, but also those who are impacted by the train system deployed – the town people who enjoy the river. And while they are not direct users, you cannot ignore them – they might actually put up big roadblocks to deploying the system.

Anyway, if you can imagine how hard it is to get 200 users aligned – now imagine you have 30 types of stakeholders with a couple hundred of each and most of them will never actually use the thing you are building. Try to keep that group satisfied!

Live from INCOSE 2008

I think this is becoming a new favorite pastime, blogging from conferences! I’m here at INCOSE 2008 in the Netherlands, specifically the beautiful old town of Utrecht. In case you are not familiar with it, Utrecht is the oldest town in the Netherlands, about 30 minutes by train from Amsterdam.

I have been here a few days now, acclimating from jet lag and touring about. In some ways it feels just like home – a university town, with people in orange running around the streets celebrating at night (and drunk). The difference is that instead of cheering for UT’s latest victory, they are cheering for the Netherland’s football wins at Euro2008.

Anyway, I'm here and hope to do some posting "live from INCOSE 2008" all week, as I've done in the past.

Just a quick intro to INCOSE - it is an organization in support of systems engineering. This international symposium occurs each year, to encourage sharing of new ideas in systems engineering. I'm particularly interested in the conference because I get to learn about working on large systems projects. We see a variety of both large software application projects and systems projects, and so it's fun to see the distinctions. Honestly, many of the concepts, methods, and tools apply to systems and software projects. But in some cases, there is much more complexity in large systems projects that brings out new requirements challenges.

One of my favorite parts of this conference is hearing people's examples. There are a lot of people from the transportation industries in Europe, with fantastic projects for railroads, waterways, and aerospace.

Are UI Requirements Software Requirements?

User Interface design is often assigned responsibility for look-and-feel. While I understand the importance of UI design, I am highly dissatisfied by its reliance on "heuristics" and, frankly, the uneven quality of those who profess expertise in the subject.

I submit that UI needs a haircut -- that we should limit the scope of what falls into the realm of UI. I think look-and-feel might be a better overarching category, but even that is too broad. The underlying flaw is that practical UI is rarely formally tested and less frequently permanently linked to business objectives.

The next revolution in requirements will be traceability or -- as I prefer to say -- connectivity. To me, traceability implies a one-way progression from objective, to requirement, to specification, to development, to test, with each transition as a one-way gate, during the passage through which one must abandon all hope of returning. Connectivity, on the other hand, is the continuous, two-way link between

• Business Objectives


• Marketing Objectives


• Functional Requirements


• Development


• Testing


• Usage

Such that any shift in one puts pressure on the others. It is connectivity that provides for not only rapid development, but presents the possibility of instantaneous development. Being able to modify a product this way depends wholly on being able to pick up the thread and see where it tugs. Before this was left to intuitive judgments, which were imprecise and incomplete leading the product into an inevitable "slow drift" away from the original business objectives.Imagine that you wanted to capture a certain "feel" as a marketing objective...

Why? Well, let's say that you believe "slippery" is the feel that would increase sales for a certain segment (amphibian programmers, say). If you can make that testable connection, even if it proves that there is no correlation, you have created an underlying framework to test your inference.

Even the softest requirements should be "connected" to business goals. If creating such connections seems like too much trouble for the requirement, chances are you're not dealing with a requirement in the first place.

Thomas the Tank Engine on Software Requirements

At my house, we recently entered the phase of fascination with Thomas the Tank Engine. If you're not familiar with Thomas and his many, many, many friends on the Island of Sodor, then you must not know anyone between the ages of 2 and 10, because they're a hit with that crowd. In fact, my son has decided that he'd rather "watch Thomas videos?" (said in his cute little "please" voice the first time) ... "watch Thomas videos" (said a bit more directly the next time) ... "WATCH THOMAS VIDEOS!!!" (you get the picture) than do just about anything else. So, I now am learning a lot about Thomas and his friends.

One of the most important things on the Island of Sodor is to be "really useful." The engines spend a lot of time worrying about whether or not they're being useful and trying to find new ways to be more useful. The highest praise a tank engine can receive is for Sir Topham Hatt (who runs the place) to tell the engine how useful he or she has been.

Being Helpful Isn't Enough

I've spent more time than I'd like to admit wondering why being useful is the most important thing on Sodor. Why not being helpful? Or being friendly? Or sharing? Or eating your vegetables? Or any of the other lessons that kids need reinforced? Is rail baron Hatt on to something?

When I put the question in terms of requirements work, it makes much more sense to me (which probably says something about the odd way I think). When working on a requirements project, it's great to be helpful and friendly and share (eating your veggies is a good idea, too, but of less importance in this case). However, all of those qualities may not actually help you do the job a requirements engineer is supposed to do.

Provide Useful Software Requirements Work

If I'm helpful in supporting existing processes which enable the project to fail, that's no good. If I'm friendly but let the stakeholders change requirements willy-nilly, that's no good either. And if I share the requirements information with the development team but they can't understand it, then what good have I done?

What's more important is that I do things which are useful to the project. I suggest (dare I say "implement"?) process changes which will help the project succeed. I force the business to make hard decisions about scope. I work with the dev team to make sure that the requirements are understood. And in doing so, I am "really useful indeed," as Sir Topham Hatt would say.

And then I eat my lima beans.

Is Your Product Knowldege an Asset or Liability?

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

"In a nutshell, the more product knowledge you have, the less product
management you're doing because your product knowledge gets you sucked
in to a plethora of non product management issues."

"Furthermore, too much product knowledge leads to micro management - the kiss of death for anyone in a leadership role."

"Detailed product knowledge = liability because you can't see the forest from the weeds."

"Detailed product knowledge = liability because it forces you more into 'how' features should work instead of 'what's needed and why' from a business perspective."

"The more you know about your product the more difficult it is to position its true value. "

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn't truly mitigate the liabilities. Good product management is fundamentally about good product management.

It's your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Secret Skills and Qualities of a Great Product Manager

I was giving some thought to what it meant to be a good product manager. There are many good posts written about the typical analysis skills found in a product manager, so I wanted to think a little outside the normal box. Here's what I came up with:

• Thinking on their feet – We spend a lot of time in front of busy users, project managers, and developers, who are smart and know their business well. At times, they are intense. They will ask tough questions of us, and probably even more challenging than that, they will state things that we need to be able to understand quickly and ask questions back intelligently. Too many blank stares, uncomfortable silences, and “uh, I don’t know”s will help us lose your credibility fast.


• Thoughtful – We are interviewers often, and so with that we must be willing to listen and think about what they say. This is different than quick thinking, but rather truly deep thinking. It will require some skills of empathy and understanding when the teams are frustrated. It will require just being someone that cares (and not faking it!).


• Likeable – I hate to say it, but we have to be likeable. We work with so many different people through the course of our work, and we really need these people to want to help us get information from them. People enjoy helping people they like, so be likeable.


• Must like people – Again, we work with so many different people who believe in us, trust us with their products. So complimentary to the last point, we must like the people we are working with. We have to want to talk to them, to tell them how it’s going, to ask them questions – simply put, we must be willing to engage in conversations. While being an introvert is very helpful to the analysis work that must sometimes be done quietly alone, being an introvert all the time will not lead to successful product management.


• Passionate –We have to love things! It sounds silly, but passionate people can feel things, both positive and negative about products around them. We can recognize and engage passion in the users we are working with. It shows itself as excitement, which can be addictive in a group.


• Excellent Reviewer – Not only must we elicit and document requirements, we have to self-review and peer-review the work. Being able to find missing items, or inconsistent requirements across volumes of data is not trivial. There are models and tools to help this, but so far, none of them completely take the thinking out of it. I have found that this is one of the most challenging skills to teach someone to do.
  

Get More Productivity Out Of Your Email

Have you ever received an email and all you could think was “Okay, so now what?”

Or, even worse, you go off and do some work in reaction to it and then find out the email was FYI, no action expected?

Unfortunately, I have. Both cases. And, I'm afraid to admit, I’ve probably sent a few emails that had the former reaction, if not the latter.

After a less than productive email exchange the other day, I remembered a guy I used to work with who had a hard and fast rule: “Before I send an email, I ask myself what action I expect the recipients to take, and make sure that it is clear.”

Good advice. It sounds so simple, so obvious. Yet, since a coworker and I both needed the reminder, I thought I’d share it.