According to a study by Dr. David P. Norton, of the Palladium Group and Cognos Corporation, nearly 90% of companies are having trouble executing their corporate strategy. However, the ten percent of companies that do manage to execute their strategies achieve dramatic benefits. If your department or company has trouble in this arena, I recommend that you do a quick self-evaluation in the following four areas:

• Executive leadership - Do executives do everything in their power to enable your group to achieve your objective?
• Organizational structure - Does the organizational structure prevent your group from achieving your objective?
• Process paralysis - Do your existing processes prevent you from being able to achieve your objective?
• Bad goals - Are your goals achievable?

It is worth noting that bad goals are often cited as a reason for failure throughout industry. Fortunately, bad goals are simple to correct using techniques such as SMART goals. There are five guidelines for making a goal SMART:

• Specific - The goal should be exact regarding what the team hopes to accomplish.
• Measurable - When a goal is measurable, the team knows exactly when the goal has been achieved and what has been achieved.
• Agreed upon - Everyone involved in the process in question, especially all Six Sigma team members, must agree to the goal and agree that its successful completion is important. At some point, all team members and project stakeholders will be asked to contribute their time and resources to the project. Agreement commits everyone to achieving the same goal.
• Realistic - Whether a goal is realistic depends on the resources and needs of the organization. Make sure the goal is neither too ambitious nor too trivial. Make it just right.
• Time frame - Like all the elements of the project goal, the time frame should be realistic. The time frame should be achievable yet limited enough to make the goal valuable to the company.

By their well-defined nature, SMART goals help keep an organization or project team focused and dedicated to a common vision.

References:
Read the full study by Dr. David P. Norton: Making Strategy Execution A Sustainable Competitive Advantage
Read the article on the Be Excellent™ blog entitled "Making Strategy Execution A Sustainable Competitive Advantage"
Read the article on the Anticlue blog entitled "Six Sigma Creating SMART Project Goals"
Read an article on SMART goals from Raven's blog entitled "10 Tips for Setting SMART Goals / Objectives"

If you already have some degree of Project Management practices at your company, why would you hire a consultant to review those practices?  As a consultant, I get asked this question all the time.  Believe it or not, the answer is very simple and compelling.  Since it comes up frequently, I have decided to make a top 5 list on the blog.

1. A consultant provides objective feedback - Since consultants are not part of company politics they lend credibility to arguments impartially
2. A consultant provides a fresh set of eyes - Consultants will offer a different perspective on your ideas making them more comprehensive
3. A consultant can be a source of ideas - The very nature of consulting exposes people to many ideas and implementations that they can offer your business
4. A consultant can be your sounding board - Consultants can validate your ideas and give you the confidence to pursue them
5. A consultant can keep you accountable - Having the consultant review, probe, and strengthen your ideas helps keep you focused on meeting your company objectives

Have you had experiences with consultants that would add to this list?  If so, leave a comment.

This is an exciting time to be in the Project Management and IT industries, as both are rapidly maturing and adhering to common processes and best practices.  However, this is a daunting time to become a project manager or IT consultant.  Lots of frameworks, best practices, and methodologies are competing for your attention.  Some are good, some are bad, but most are "good in certain situations."  All of these new ideas remind me of a profound saying that I learned in college:

"In theory, theory and practice are the same.  In practice, they are not."

An example of this recently came to mind for me.  The IT Infrastructure Library (ITIL) framework is completely based around the idea of a Configuration Management Database (CMDB).  In theory, the CMDB combines information about all aspects of an information system, the business areas it supports, and service levels.  However, in practice no such database system exists.

If you are considering an ITIL implementation, please read the IT skeptic's blog.

On her Project Management blog, Raven's Brain, Raven discusses the possibilities of a Web 3.0 movement. Much like Raven, I am very skeptical of a new layer of intelligence on top of the shaky foundation that is Web 2.0. In fact, I remember when Web 2.0 was just starting as a movement and was itself promised to be "semantic web." Unfortunately, the reality is that this sort of "machine thinking" that Web 3.0 promises is still out of our reach today. Still, Web 2.0 delivered a much-needed infrastructure for shared information the likes of which the Internet could not hope to achieve without technologies such as Web Services, RSS, and AJAX. However, I believe that Web 2.0 still has much to accomplish before the groundwork for the next layer of intelligence is established throughout the Internet.

Web 2.0 still has a long way to go before we can even think of building on it as a stable platform. Among the current problems with Web 2.0 are:

• Some overestimate the power of automation via Web 2.0 technologies.
• Tagging is a very powerful technique but has so far not yielded much of its promise.
• Blogs constantly suffer from comment spam.
• Companies have yet to adopt public web services widely.
• Browsers are just starting to converge on a standard interpretation of web standards.
• User edited content such as wikis have yet to prove widely useful outside of the Wikipedia project

Despite these shortcomings, Web 2.0 has given us many useful tools and services. My favorite among these are:

• Wikipedia - http://www.wikipedia.org - Wiki encyclopedia
• YouTube - http://www.youtube.com - Video tagging and sharing site
• Live Spaces - http://spaces.live.com - A personal content sharing/blogging site
• Flickr - http://www.flickr.com - Photo tagging and sharing site
• Last.fm - http://www.last.fm - Music tagging and recommendation site
• MySpace, Facebook, etc. - Social networking sites

What are your thoughts on Web 2.0 and 3.0? Also, post up your favorite Web 2.0 sites in a comment.

When should you kill a project?

This is a topic that is rarely discussed in the industry because of the stigma of failure.  No one wants to look bad in front of his or her customer.  So they crash (add resources), fast track (do tasks in parallel), and generally throw good money after bad until a project completes or becomes impossible to complete.  This problem is typically magnified in companies where a project manager's reward is based on successful project completion.  However, as project managers it is our duty to monitor the health of a project and if the time comes where it makes sense to kill the project we should advise our customers honestly.  How do you know when the project really needs to be killed?  The answer is very simple.  There are three reasons to kill a project:

• The company strategic plan has changed and the project no longer aligns with business goals
• The cost of completing the project is higher than the expected return on investment
• The project is meant to exploit a window of opportunity in the market but it cannot make the schedule

If either of these conditions are true, kill the project.  I will go one step further and say this: kill the project as early as possible.  All good poker players know that it is better to fold early and only bet big when success is assured.  I have been on several projects where management did not kill troubled projects in a timely manner only to find that they spent more than planned and did not get the result they were hoping for in the end.

In my experience, the top two reasons that projects are not killed when it makes the most sense are:

• Fear of failure
• Project managers who value completed projects over fiscal responsibility

The first reason is a false belief that one looks good only when they are finishing projects.  This is the leading cause of reckless project management techniques to make the deadline no matter what.  However, from a business point of view, a project manager looks much better at review time when they demonstrate a fiscal responsibility to management.  Five killed projects for minimal losses and one successful one that makes a huge return is more beneficial to a client than pouring money into one troubled project that will ultimately not achieve its goals.

The second reason that projects are not killed timely is just plain irresponsible project management.  This happens when a project manager worries more about looking good in front of their boss than the interests of the company as a whole.  These project managers will sometimes whitewash information, hide facts, or generally make a project look healthier than it really is.  In the end, these projects inevitably fail to achieve their objectives.  Unfortunately, even if the project is ultimately unsuccessful these project managers succeed in convincing or deceiving management into investing more money than is probably prudent.

Do you have stories of projects that should have been killed but were not?  Leave a comment for the benefit of all the other project managers out there.

• The quality of a system is highly influenced by the quality of the process used to acquire, develop, and maintain it.
• Process improvement increases product and service quality as organizations apply it to achieve their business objectives.
• Process improvement objectives are aligned with business objectives.

• Executive dedication to process improvement
• Quantitative measurements/assessments
• Process review/modification based on feedback
• Stringent adherence to existing processes by everyone

This sounds hard, but it does not have to be.  Guides such as CMMI, provide a direct path from hero-based (level 1) operations to optimized, consistent, and managed (level 5) enterprises.  Additionally, Carnegie Mellon's Software Engineering Institute provides a formal CMMI appraisal service to formally validate an organization's maturity level.  However, this is not strictly necessary as the formal validation does not accomplish anything that an objective internal review would show.

If you have any experience with CMMI, SCAMPI reviews, or process maturity in general, please leave a comment.

Consultants often visit client sites to do our jobs.  We typically bring our laptops with us and connect to our client's network.  At this point in our relationship with the customer, I believe it is our responsibility to protect the customer's network from cyber attacks against our laptops.  The client is typically put into a very vulnerable position when our laptops connect to their network.  Imagine your client's reaction if they find out that your laptop spread a virus on their network or served as a gateway for hackers because you had wide-open wireless settings.  This would tarnish not only your reputation but also the reputation of your firm and the entire profession in general.  Having updated antivirus software and latest Windows patches is common sense; however, as consultants we have a professional obligation to go beyond the basics.  We must protect our laptops from exploits targeting wireless flaws that could render our client's data public.

Recommendations:

• Antivirus: avast! antivirus
• Firewall: Windows Vista Firewall or Jetico Personal Firewall
• Encryption: TruCrypt
• Secure Erase: Eraser
• Wireless: Turn this OFF physically unless needed at the client's site
• Screen: 3M Privacy Filter (protect sensitive data when working offsite)

If you have a story regarding an experience on this topic, please leave a comment on the blog.  I would love to hear them!

PS: There are ways to protect a network from potentially harmful computers.  To learn more, look into Cisco Network Admission Control (NAC) and Microsoft^® Network Access Protection (NAP).  Microsoft and Cisco have agreed to an architecture that combines both offerings as detailed in the NAC-NAP Whitepaper.

"Try this exercise. The next time someone (even you) makes a statement that sounds like a declaration of fact (an assertion that this is so, this is the way it is) ask, “How do you know?”

Then wait, and press if you need to, for an answer.

Don’t be surprised if you get one of two of the most common replies to that interrogatory: Common knowledge, or, my experience (or variations on these themes). Follow up these replies with a quest for more clarifying information.

“Common knowledge?”

“Yeah.”

“What do you mean?”

“You know.”

“I don’t want to make any assumptions here. Why don’t you tell me more about what you mean by that.”

If they say, “My experience tells me this is so,” you can reply with something such as, “You have direct experience with a situation just like this?”

“Yup.”

“Great. Tell me about that." -- Don Blohowiak

It is inevitable. At some point in time, either you or your employee will miss a deadline. Sometimes that deadline will affect customer deliverables and make you and your organization look bad in front of a client. This is the subject that caused Trizle to come up with a shortsighted initiative he calls "No Deadline Left Behind."  The premise behind this idea is to punish employees monetarily for missing deadlines. On the surface, this seems like a reasonable, maybe even sensible, policy. After all, an employee should be incentivized to meet contractual obligations. However, after some analysis this approach, though intuitive, is the wrong one.

It seems that Trizle means to punish employees for the failures of the project manager. Most deadlines are missed because of poor estimation, risk management, and progress tracking. Unless those areas of Trizle's process are fixed, he will just shift the blame and punishment of the problem on the poor employee who has little control over the actual deadline itself. The result of such a policy will be inflated timeliness (as employees seek to minimize their risk), higher costs (employees will charge more for some work to offset loses in other work), and no improvement in the ability of an employee to consistently meet a deadline. Furthermore, employees will reach a point where the risk of losing their income becomes so high that employment at Trizle's company will no longer be a viable option for them. As an example, Rob Garrett's response to this article demonstrates a typical employee's reaction to such a policy.

"No Deadline Left Unmanaged"

Instead of the "No Deadline Left Behind" as Trizle suggests, I have come up with a realistic strategy. The strategy starts in the planning phase of a project. Here, the typical pitfall is poor estimating. While it is common to use a team member's expertise to judge the effort required for a task, this path is dangerous and should be only used as a last resort. Instead, use techniques like parametric models, commercial databases, or weighted averages to get estimates that are more accurate.

Parametric models are mathematical formulas used to estimate the total duration of a task based on variables. For example, "it takes me 2 minutes to lay 1 tile, the tile is 1 foot by 1 foot, and the room is 100 sq. feet. Therefore, it should take me approximately 200 minutes to lay enough tiles to fill the room."

Note: Problems that are more complex require models that are more complex. Additionally, pay close attention to how well the model scales (it may take 2 minutes to lay 1 tile in a small room, but increasing the room size may not increase the total time in a direct proportion)

Weighted averages, such as used in the PERT technique, allow a manager to consider an optimistic estimate, the average estimate, and the pessimistic estimate to come up with a figure that is realistic.  The PERT formula for this is:

T_E = (O + 4M + P) ÷ 6

Where O is the optimistic estimate, M is the average estimate, P is the pessimistic estimate, and T_E is Expected Time. Performing a standard deviation analysis can show the manager how confident they can be in the estimate.

After these techniques are used to come up with estimates that are realistic, it is paramount to control the scope of the project to prevent missed deadlines due to scope creep.

The second phase of the strategy comes into play during risk management. Each employee should be positively encouraged and incentivized to report project risks to the PM (or risk management officer) immediately. The PM can then form a risk response plan to accept, mitigate, or transfer the risk of a missed deadline. Accepting a risk means realizing that a risk exists but doing nothing to prevent it. Mitigating the risk of a missed deadline could involve adding resources (crunching), re-negotiating the deadline, or doing tasks in parallel (fast tracking). Transferring the risk could involve obtaining an insurance policy (this moves the risk from you to your insurance provider).

Note: Punishing employees for missing deadlines is a form of transferring risk because they end up paying for your mistakes.

The third phase of the strategy is for the PM to be intricately involved in the monitoring and controlling activities during the execution phase of a project. A manager that does not track progress until deadlines are missed should shift their focus onto actively managing their people. Tools like EVM (Earned Value Management) are essential in effectively tracking project status. EVM allows the PM to "objectively track physical accomplishment of work [by] combining measurements of technical performance (i.e., accomplishment of planned work), schedule performance (i.e., behind/ahead of schedule), and cost performance (i.e., under/over budget) within a single integrated methodology."

In my opinion, these three improvements in the project management area will drive improved management of resources, risks, and schedule in a much more efficient manner than transferring risk to your own employees.