Ten learned commandments
Alexandre Novaes Olivieri, Program Manager, Motorola
Year after year, countless projects have been having their “Lessons Learned” captured and analyzed. Still, the biggest complaint is that projects continue to fail and surprisingly share similar reasons for doing so. The objective of this article is to point out “WHAT TO DO” in a project, as opposed to the “WHAT NOT TO DO” statements that are the usual products of a lessons learned session. The lessons mentioned in the article were learned in an information technology and software development environment within a manufacturing enterprise. The article will also discuss manners to collect this type of “positive statement” lesson items in an effective way.
Learn How to Learn—Introduction
How many times have you seen outputs of Lessons Learned in the format “DO NOT something,” or “NEVER something else”? Well, if the projects you have worked on are somewhat similar to the ones observed by the authors, many times.
When you ask someone to guide you through a path, for instance, a GPS helping you to get somewhere, it is designed, on purpose, not to use DO NOT or NEVER. It always uses positive statements about what to DO. This is giving you ONE right way to get there. It is not about telling you all the paths that will NOT work.
The human mind is more prone to accept, absorb, and follow positive commandments, just because they represent one way to get it right, instead of one way to prevent it from going wrong. Neuro-linguistic Programming and Positive Reinforcement say that human minds ignore the negative part of what is said.
That is why this is the first commandment in the article—and the most important one. Learning how to learn is about giving people options about how to DO things right. All the commandments will have as titles their short form, and will be spelled out in a practical and informal way. Again, they will all talk about what WORKS in projects, not about what does not work.
Any Project Shall Be Estimated Accurately—Once It Is Completed
No matter how much the project manager invests in risk management, project buffers, and alternative project methodologies, two things will not change: estimates will always be required in some instance and they will always be wrong. This commandment intends to show that this is a reality in projects, and help project stakeholders to deal with it instead of fighting it. Basically, the questions to be answered are: How to estimate? When to estimate? What is the confidence level?
To help answer the first question, an objective point must be made: use data to estimate, always. If there is no historical data in your organization, start creating it (the sooner, the better). Look for alternatives like benchmarks in the industry, or as a last resort, in the literature. That would apply for work size, effort, and duration. Try to start by the size, which would be the most concrete variable you may have (e.g., lines of codes). The effort will depend on your organization’s productivity, which should be in your database too— by the way, effort is NOT duration. Lastly, when setting the duration remember that your resource is not a machine and will not work eight hours a day. If there is no database, be conservative and use no more than six hours. The rest will be consumed by your several mitigation and contingency plans that will emerge during the project. Buy this idea!
Another topic that drives project managers nuts is when to estimate. Generally, it would be tied to the project commitment, when costs and durations need to be agreed upon with the sponsor or customer. But the right time to give this commitment is key, as the Cone of Uncertainty discusses. When talking about software, it is being proved that you need to start your development earlier (for instance, prototyping) to have as much information as you can when it is time to provide the estimates. Agile software development is being largely adopted due to implementing this approach.
The last question—what is the confidence level—is tied to the other two, but it has special importance. Estimations are, by nature, uncertain. If they were certain, they would be historical data, facts, not estimations. All estimates need to have a clear picture on their confidence level, based on which data was used to estimate and what was the comprehension of the project scope, risks, and so forth ... that is, how long have the estimators been involved with the project when they provided the estimates?
In a nutshell: estimates will be wrong, but you need them.
In God We Trust—For Project Status, Bring Data
“The project is on track!” If this is the best you can have in terms of tracking on your project status report, do not hesitate: call 911! Despite the drama in this joke, this commandment intends to warn all project stakeholders to the damage the lack of quantitative data can do to the project. Remember that a project gets one year late one day at a time.
First of all, there is a need to kill the myth that having quantitative data will overload the already overloaded project manager. No need for ninjas or black belts in the staff to manage this. Today most of the project management tools already implement Earned Value Analysis, for instance. Even if you do not have access to these tools, a one-time configured spreadsheet will do the work.
Another key concept to keep in mind is baseline. A project without a baseline set will never be able to do true quantitative reporting. The report must always be made against the baseline and never against decisions made after the baseline is established. A baseline can change, but a very well defined process needs to be in place to change it. Involve the cops if necessary. Otherwise project reporting will never give the true picture of the project.
Finally, some words on the benefits of quantitative reports. The most important is that you should improve your stakeholders’ commitment after they start receiving all these numbers and charts reflecting current project status. Instead of saying that the project is behind plan and asking for extra effort to (probably) recover the delayed project, the project manager will show SPI and CPI numbers that will prove that a quantitative amount of effort can put the project back on track. The project manager can congratulate the team whenever the charts improve, link it to their efforts, and will probably have better arguments to show how their actions have direct impact on project status (and on the sponsor’s mood). Complaints also tend to decrease when numbers are used to prove something.
If It Can Go Wrong, It Will
All project managers would probably learn a lesson or two by studying some of Murphy’s laws. A computer science graduation class chose Murphy as its patron, for good reason—a four-year course can teach anyone that “If anything can go wrong, it will” (Murphy’s Law).
The most common lessons learned in projects are related to risk management: when people do not fail do identify risks, they fail to manage them.
Thus, this commandment is about how to deal with risks, and is divided into two parts:
One shall always LOOK for risks. It is an active and continuous hunt for risks. Risks that just jump out in front of your eyes are usually not good enough, not complete enough, and not even risky enough. “Brown bag” (or informal) conversations with team members and other stakeholders is a wonderful source of risks, usually risks more important than the ones people get in a formal session. So, hold formal risk identification sessions with your team, but also have regular informal conversations to identify risks and issues.
If you are a project manager, you probably already go to a shrink. So, wear your shrink hat during these sessions. Let the person talk—you can always classify and label it properly later. Using the word risk or issue inhibits the one mentioning the concern, and that is the opposite of what you want. Concentrate on listening and asking probing questions to learn more about the concerns. So far, this has proven to be the richest source of risks and issues identifications in practice, and has very low cost—a coffee, a cup of tea, a cookie, and a sincere desire to listen about the project’s concerns from each team member. Trust more those who stand to lose as much as you when things go wrong with the project.
Every time a risk is found, any action related to it—whether mitigation, elimination, or transference—must be immediately inserted as part of the overall project plan, in the actual schedule, with all the other tasks, with assigned responsibility and dates. If the actions are dealt with separately, as if they are a different animal, they simply get overlooked. Risks are just a different source for actions that are regular part of the schedule.
Just like any other tasks, progress on the risk management will show up in your CPI and SPI. That makes a huge difference to immediately see when something is falling behind.
Beware of Dependencies
Every software work product needs a platform to run on. If it is an ERP system or an embedded piece of software, this is always true. And, if your software projects are at all similar to other software projects, that small piece of information is often overlooked. Although it seems some hardware pieces are commodities, it is not the commodity that is usually needed. Usually the project depends on special orders to be fulfilled by a third party supplier. Some depend on internal groups of your own company to be produced.
This brings up the fifth commandment: manage dependencies as a part of your project. Not as external elements. Not as a separate section of assumptions. Manage your dependencies as part of your project—and, usually, as part of your critical path. Just as mentioned in risk-related actions, dependencies must show up as part of your plan, in such a way that they affect, at least, your SPI, in case they get derailed. This triggers more immediate action and gives a clear view for all the stakeholders on where the project really stands.
Project success is measured by having the entire systems solution ready, not only the software piece—and that means having all dependencies clearly spelled out and managed as any other activity of your software project.
Manage By Walking Around
The idea behind this commandment is to show the importance of human communication during a project. Two important points that should be considered in this analysis: (1) a project manager spends around 90% of the time communicating; (2) the vast majority of communication is non-verbal or oral. So, in order to succeed, the project manager should keep in mind that much more is required than status reports, emails, instant messaging and other communication mechanisms that do not have direct contact with the project stakeholders.
It is very common for project managers or leaders to spend most of their time at their desks, responding to emails, filling out reports, and meeting with the project members on a weekly basis, and thus failing to realize that a great deal of communication is being lost. The only way to receive and transmit the information through facial expressions, intonation, and body posture happens when the project manager has direct contact with the team member and uses both non-verbal and oral communication. This commandment alerts the project managers to implement these techniques in order to improve the overall project performance.
And this is not a big deal at all. The project manager can start by asking a simple question: Have I at least seen each of my team members today? If the answer is no, go for it. Start the MBWA technique (Managing By Walking Around). Go grab all the information that is vital for project management. Things like voice quality, emotion, tone, stress, clothing, hairstyle, eye contact cannot be determined through instant messaging. For instance, the project manager can realize in the first hour of the morning that a team member is very upset, find that the root cause is dissatisfaction with the current task assignments, move the team member to a more interesting task, and by the end of the day the overall productivity will be increased. A daily mood meter may help on this.
One pitfall that should be avoided is the project manager’s own mood. Remember that the leader is not only receiving information, but is also sending precious non-verbal messages to team members. Verbal communication is organized by language, but non-verbal is not. The leader should always transmit boldness, leadership, and happiness, and avoid elements that would contaminate the atmosphere in a negative way. This should be seen as a great opportunity for the leader to motivate the team and keep up the stamina.
Having said all that, it is worth mentioning that we are not naturally able to “read people.” We need to practice building this ability. There are several good references in literature on this area. Make it work for you.
Tests Shall Fail
The truth is out there. So are the bugs! Regardless of how much you invest in quality, ultimate development tools and techniques, modern process and procedures, your project will not be bug free. The main root cause is probably related to the human factor, always part of the development chain. Your test efforts are your last chance of finding them, leading you to a very down-to-earth conclusion: project tests shall fail!
Three points to keep in mind when deploying this commandment. The same humans that introduce the bugs are the very ones optimistically creating the project plans. People tend to believe that everything they create works, or at least they do their best to make them work. Here’s the first point: people will naturally under-estimate the test phase and not give it the importance (read: effort and time) it requires. Overlooking the test plans is also a consequence of this “self-protection” approach.
Second point: create a rewarding environment during the test phase. Testers shall be recognized not by making the project report green, but to find the real bugs. Yes, make them red as much as they can. Reward the top bug finders. It is very common to see project managers and stakeholders doing what they can to turn the reports green. In most of the cases it represents the project successful completion, and bad decisions are made based on that.
Lastly, another important thing to keep in mind is that you will never catch all the bugs. Project plans must not have this hard assumption. And you will never be able to prove that your software is bug-free. Finding the ones that represent the biggest risk to your project is the way to go. Some will say that software testing is an art—better the art in red than green.
The World Shall Be Flat
The first time someone is part of a global team, it always triggers a kind of pride in feeling part of a bigger world. However, it is scary to think that while it is a comfortable 9 a.m. CST, it may be already 10 p.m. in Beijing and 6.30 p.m. in Bangalore, where the other co-workers are. It is scary to think that the language to be used by a team composed of members of nine different countries is the native language of only one of those countries. It is even scarier to think that each one of those team members inherits a set of behaviors that was molded not only by their families, education, and formal professional preparation, but mainly by whom they are as individuals, in the context of the culture they have grown up in. Scary or not, that is a reality that every project team will face sooner or later (and, nowadays, it is likely to happen sooner than later).
If a project team is global: respect that fact, consider it, and plan for it:
- Ask team members from other locations if it would be better for them to rotate meeting times so that a different country periodically gets the evening time, not to overload anyone’s evenings. Do not assume they will prefer that, because work unfortunately may have already made them change their lives and habits to be available in the evenings, and a change that could look nice to you would mess up their already adapted schedule.
- English will probably be the official language. But if the vast majority of the team has another language in common, encourage them to use it when discussions are difficult or when something needs absolute clarity. It is better to have two or three parallel discussions in different languages but, in the end, ensure that everybody understood things despite a language barrier.
- Written documents are good, but pictures and diagrams are universal (they depend less on words and language). Use them widely.
- Encourage teambuilding, even if virtual, to allow team members to know each other better. Not only at the individual level, but also at the country and culture level (e.g., ask each team member to talk about a key costume in their country, a key dance or festival, and present it to other team members).
- Learn and understand about other cultures’ intrinsic behaviors and beliefs. In some cultures, workers are taught to be neutral. In others, not to ask questions immediately. Some have a high respect for hierarchy and will never challenge someone in a higher position directly, even if they disagree and the other person is open to listening. Learn about those differences up front and plan to address them in your project (e.g., using a third party at the same level of the team members to get their concerns, scheduling follow-up Q&A sessions for teams where the culture is not to ask questions immediately, etc.). This will allow you to make the best of the differences and build a winning team based on diversity.
Scope? Change It!
It is more likely for you to find an elf on your way home from a painful project tracking day than to have no change in your project scope. This commandment does not intend to change you into an elf-believer, but rather make you buy the idea that project scope has a great chance to change and the cost of changing will increase the later you identify them. The question is, when do you want to find these changes?
Some facts are hard to avoid. Some are very common across projects: the customer does not know exactly what is wanted; new technologies have a great amount of intrinsic uncertainty; the world is changing faster than we can control or picture it; projects usually do not plan enough time to scope down to a level where uncertainty and changes can be minimized.
It is true that scope changes are usually labeled a bad thing. Costs will increase and the project will be delayed. Project managers and sponsors panic whenever a scope change is raised, and all the effort is to minimize this. It is a mistake to say that a project was completed successfully if all the scope agreed upon in the contract is met, but later the solution does not meet the customer’s needs or its return on investment.
The goal is to go in the opposite direction. The project manager should encourage a continuous critical analysis of the current scope. It could be as simple as a regular meeting to criticize the current project scope—the sooner, the better. Document the criticisms and consider it the list of Critical Success Factors for the project. Try to prioritize the ones that the customer can complain about. Next priority would be the ones that testers would reject when evaluating them—try to handle these before your project is in test phase.
Lastly, always remember goldplating. Make sure you are not adding bells and whistles to your project, but uncovering the value-added things needed and not identified yet.
Learn How to Learn
This one looks like a repetition of the first commandment. It is not. It reinforces that learning is a circular process, never ending. But it also suggests an approach to conduct lessons learned, especially on unsuccessful projects, and still drive positive statements from the team. The approach described below is based on the DMAIC steps of Six Sigma, but this is only one valid approach among many others.
Design and Measure
It’s all about pre-work!
- Design your data collection (criteria, quantitative, and qualitative data). For example, a survey (quantified) with free comments fields for each response: the trick is that you can only use the free-text IF you answer the quantified part also.
- Get the participants’ input offline—that is the venting opportunity for all the emotion they have and an essential tool to analyze the passions in a positive way. Paper accepts anything: calling people names, blaming people, and all other things that are not supposed to ever happen in a lessons learned live session.
- It must be clear (repeated ad nausea) that consolidation will be made by a neutral party—someone who has absolutely nothing to do with the project or project team. Feedback will be compiled and never tied back to their originators.
- Consolidate pre-work data. Quantified items are grouped together and a decision made on what are the top priorities to be addressed in the lessons learned live session.
- Scrub every piece of free comment, group them by affinity, eliminate names, rephrase finger-pointing without losing the key message, and so forth. This material is then put in a presentation format, and will be used in the live session.
Improve and Control
- In the lessons learned live session, if at all possible have the entire team participate. Present the compiled material. Then, discuss in detail the top priorities identified in the pre-work. For those, all comments grouped by affinity are pulled up, and the team is requested to work on:
- What was the root cause for what happened?
- How to DO it differently next time to address that root cause before it even happens?
- What controls can be put in place to prevent root cause reoccurrence?
- With this approach, solutions and controls are always “DO IT” commandments, ultimately. That helps to keep the positive statement philosophy, and also takes the lessons learned to a new level of performance, since the team is not only whining about problems, they are proposing the solutions as experts on the problems, preventing them to happen again in the future.
- Divide the team into sub-teams during the live session, if needed. But it is essential that the entire team has a chance to see and agree upon the compiled set of actions that will drive future projects toward success.
- Ensure that the results get published to the entire organization, and institutionalized (through changes to the process, training, and so forth). One of the things that works well is to publish a list of the top X learned commandments (like this list) made in small laminated cards so people wear it behind their badges. Nobody could argue that they were not aware about how to DO those X things right.
Even when using this approach for lessons learned (the Six Sigma approach, plus reinforcement on the positive statement outcomes), this does not ensure the success of a project. It will improve the chances of success in the areas for which you provide specific DO IT statements. Yet, every project has its own nuances and much more areas to be covered that will escape the DO IT statements. The hope is that by combining and repeating these methods over and over, some of the DO IT statements are not commandments anymore; they just become the only known way to do things. And this will give room for new DO IT statements to appear. As the Danish philosopher Piet Hein once wrote, “The road to wisdom is plain and simple to express: to err, and err, and err again, but less, and less, and less.”
Agile Manifesto. Retrieved 08/06/02 from http://agilemanifesto.org/
Cone of Uncertainty. Retrieved 08/06/02 from http://www.construx.com/Page.aspx?hid=1648
DMAIC. Retrieved 08/05/05 from http://www.isixsigma.com/dictionary/DMAIC-57.htm
Free Six Sigma lessons. Retrieved 08/05/05 from http://www.motorola.com/content.jsp?globalObjectId=3069-5787
Friedman, T. (2005). The world is flat. New York: NY: Farrar, Strauss & Giroux.
Neuro-Linguistic Programming. Retrieved 08/06/02 from http://en.wikipedia.org/wiki/Neuro-linguistic_programming
Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® Guide) (2004 ed.). Newtown Square, PA: Project Management Institute.
Project Management Institute. (2005). Practice standard for earned value management. Newtown Square, PA: Project Management Institute.
Reinforcement. Retrieved 08/06/02 from http://en.wikipedia.org/wiki/Reinforcement
Weil, P., & Tompakow, R. (2001). O corpo fala. Brazil: Vozes.