In many cases these changes will be very small, such as changing contact information e.g. a telephone number or adding a news item. Other changes, such as new products or a new business focus, will necessitate more complex updates to the site. The good news is that you'll probably only need to change the text without modifying any of the existing graphics or page layouts. This is where a content management system shines; allowing you to change the content of a web site without having to worry about the technical details. Any web site with more than a handful of pages shouldn't be without a CMS.

So What Is a Content Management System?

A content management system is a software package specifically designed to manage a web site. Custom systems are often developed by the same team building the web site for which the CMS is being built. Off the shelf solutions are installed by the webmaster and configured to work with a particular web site.

Regardless of who installs the CMS, the intended users are non-technical people who are more concerned with creating web content and aren't interested in learning the ins and outs of building web pages from scratch. Typically, users will access the content manager using a web-based interface that provides a simple editor similar to Microsoft Word.

Ideally, users of the CMS should just have to point-and-click, type in the new words, and then hit save button. The result is an updated web site. Adding new pages, deleting old ones, or restructuring the site to match a new business model should also be very easy to accomplish.

In the background, the CMS is automating menial tasks, such as applying the same font style, text color, and overall page layout to every page you create. The menus generally found along the top or on the left-hand side of a web site are also automatically created.

With the help of a content management system, you are able to focus on the words and your site's overall message without bothering with the underlying technology.

What are the benefits?

A content management system makes the maintenance of a web site much easier in several ways:

• You are no longer dependent on the schedule and availability of web designers to make site changes.
• All the technical details are handled by the CMS, allowing anyone to manage and update the site.
• You can track who made what changes and when.
• You can ensure that each content provider can only update the sections of the site they are responsible for.
• The CMS ensures that all the pages are consistent in design, and will build all the menus and other navigation for you.

There are many other powerful features that can be included in a CMS all of which are intended to allow the site to grow at the same pace as your business.

A CMS Within Your Budget

The good news is that a lightweight CMS, suitable for a modest-sized web site, is not expensive. The cost can be as low as a thousand dollars, or simply a complementary part of the web site building project.

In fact, content management systems are one of those rare things where you don't necessarily get what you pay for. According to a report from Jupiter Research, "…Web-based business initiatives have led some companies to spend a hefty $25,000 per non-technical employee per year to manage simple content on a web site." Furthermore, "Jupiter analysts have found that businesses with Web sites that do not operate at scale (e.g., scores of users and tens of thousands of assets) are better off evaluating lower-cost solutions, sometimes even homegrown systems."

So be thorough in your search for the right content management system and don't assume that an off-the-shelf solution is going to be cheaper or more effective than a custom built solution.

Where To Start

The first question you need to answer is, "What do I want my site to do?". Or put another way, "What should my site do for me to consider it a success?" Trying to build a site without having a good idea of the answer to these questions will cost you a lot of time and perhaps money.

When you have a one or two line description of the goal of your web site you'll need to start refining it. This task is often done by a requirements analyst (sometimes called a business analyst). The end result of this analysis should be a document describing the features of your site.

Create a Prototype

With your requirements document in hand, you are now able to begin work on a prototype. I'm a big fan of prototypes as they offer an accurate simulation of how the actual site will function when it is complete. Creating a prototype determine the main sections and navigational features of the site. When you know how people will move through the site you can begin thinking about the look of the site. If you're not artistically inclined you should consider hiring a graphic designer. Your site needs to make a good first impression, so you want it to look professional.

System Architecture and Database Design

If the content of your site is dynamic in any way then you'll need to put some thought in to the
system architecture. Things you'll need to consider are what technologies you'll want to use and
how you can use these technologies to make your site maintainable and extendable. Remember, over time successful web sites end up doing more than originally intended so you don't want to paint yourself in to a corner with some short-sighted architecture decisions. You'll also want to start working on a database design if you plan to store web content or user information.

Again, depending on your skills you can do these tasks on your own or look to getting help. A web developer with several years experience can often handle the task of determining the system architecture and designing a database.

Web Development

All the analysis and design is handed off to one or more web developers who are responsible for
putting all the pieces together and making the site functional. Usually there's nothing to see
for a few weeks while the web developers put together templates and such. However, after some preliminary work bits and pieces of the site should start to become functional so that you can review the sections as they are completed.

So Now You Have a Working Web Site

You might think that once you have a working site that you're almost done. I wish that were the case. Your next steps will include the following:

• Finding a hosting company that is reliable and cost effective
• Submitting your site to search engines. You will probably only need to do this once, but it may take a month or two before the search engines visit your site.
• Ongoing search engine optimization so that your site appears in the first page or two of search results
• Other advertising and promotional activities such as mailing lists or newsletters

The good thing is that once you reach "critical mass" your site will almost run itself. Unfortunately, there's no way of knowing how long it'll take before you reach this state, but I guarantee you'll know when you get there!

I wanted to include pages (not just posts) in the RSS feeds that WordPress generates. I wouldn't be surprised if this feature became part of the core of WordPress, but until then, feel free to download this plugin.

RSS Includes Pages Plugin

If you encounter any problems, please leave a comment below and I'll get back to you as soon as possible.

Special thanks to Aaron Waggener for providing the technical brains behind this plugin!

Version History
1.0.0 Initial Release
1.0.1 Corrections to readme.txt
1.0.2 Tidying stuff up with WordPress' version control system

Brochure Sites

Brochure sites are very common. Their purpose is to act as an extension to a company's sales and marketing efforts. They usually "don't do anything" other than provide information to prospective buyers or clients with the hope that the company will be contacted by e-mail or phone for more information. MariosAlexandrou.com is a brochure site. In my case, this site is an extension of my ongoing efforts to sell my custom software development services. On this site I include copies of my resume, samples of my work, and descriptions of some software tools I have created, but, as with all brochure sites, this site "doesn't do anything".

E-Commerce Sites

E-commerce sites are those whose primary purpose is to sell you goods. One of the most widely recognized sites in this category is Amazon.com. These sites are often the most expensive to build, but can also be the most lucrative for the owner. Those with small budgets can opt for a pre-packaged e-commerce solution such as those offered by Amazon.com and Yahoo.com, but these often fail to distinguish your company from the 100 other companies selling the same product. I'm clearly biased, but in my opinion you're better off having some custom software development done to meet your business' specific needs.

Visitors to e-commerce sites often know what it is they want and so it behooves the e-commerce site to help them find it. At the same time these sites want to show you information about other products (referred to as up-selling and cross-selling) so that you'll spend more money. Because of this need to show you what you're looking for while at the same time sell you related items, e-commerce site employ some of the most sophisticate search engine technology available. Don't believe me? Next time you have a chance visit Amazon.com. Search for anything you want. The search engine will almost always find something that matches. If you've ever searched for or bought anything at Amazon.com you've probably also noticed that related products keep showing up on the screen. That's the search engine at work.

Communities

Web communities come in all sizes, but in all cases they bring together people that share a common interest. I'm part of several software development communities. Years ago when I owned an aquarium, I visited aquarium related web sites for information and tips on how best to care for my fish. Sometimes web communities are run by people who are also looking to sell products or services. However, if the community doesn't contain useful and timely information, then any sales pitches will be likely fall on deaf ears. Tricking people in to buying something might work once or twice, but it's more effective to build trust and provide value.

Portals

Portals, as the name implies, act as gateways to information from various sources. The goal behind a portal is provide relevant information to user's without requiring the user to spend a lot of time searching. Ideally the information gathered is tailored to the visitor.

An example of this type of site is a corporate intranet portal which brings together documents and resources from many departments within the company. This can be particularly helpful when a company has many offices around the country or world. Employees of the company are then able to search for company related information that other employees have published. This information can be simple things like a phone directory or more sensitive information such as market research reports. A good example of a public portal is Yahoo.com although some might argue that in recent years Yahoo has grown beyond just being a portal.

Search Engines

Search engines are probably the single most useful tool on the Internet. Without them it would be next to impossible to find anything. By many accounts, the best search engine is Google.com. With a few clicks you can usually find answers to questions or, at the very least, a good starting point for where to look. Chances are you won't build a search engine, but it is important to know about them and understand how they work. Businesses should be particularly concerned with the details of how search engines work since they can be used as an inexpensive advertising tool.

So Now What?

There you have it. Most web sites fall in to one of these five categories. Do you know what kind of web site you want? Read How to Build a Web Site for a high-level look at building a web site.

That's where all the methodologies come in. All promise to improve the software development process regardless of how advanced your existing processes are. Surrounding all of these processes is the Capability Maturity Model or CMM for short. The CMM is intended to rank an organization's processes so that, for example, a prospective client can use the information to decide who to hire. Presumably a CMM Level 5 (highest level) company would cost more than a CMM Level 1 so there'd need to be some cost-benefit analysis done.

It all sounds good in theory until it starts to become apparent that companies can buy CMM levels and there isn't much being done to regulate the whole process. Here's the latest article I've come across about the problems with the CMM. And while I'm certain there's some sensationalism thrown in to make for a more interesting read, it's hard to ignore this story from a CMM appraiser:

After a few initial niceties, the executive leaned across the table to Smith and another lead appraiser who had accompanied her to the meeting and asked, "How much for a Level 2?"

"That's when I got up and left the room," Smith recalls. "The other appraiser stayed. And the company got its rating."

One of main points that McConnell makes in this book is that software developers need to focus more on being like engineers. That is, software engineering is more directly valuable to businesses and society than computer science.

The distinction between computer science and software engineering wasn't clear to me until reading this book. McConnell provides a dictionary definition: "Software engineering is the application of scientific and mathematical principals toward practical ends." The key part of this definition is "practical ends". Computer science, on the other hand, is more focused on theoretical concepts that although important, don't necessarily have a practical use. And because most universities teach computer science rather than software engineering, McConnell contends that there is a shortage of true software engineers.

Even though I have a computer science degree, I have to agree with McConnell's analysis. I was fortunate enough to have come across some great books and worked with some good people early in my career such that I became aware of the deficiencies in my education. So for many years I have worked towards filling in the gaps and I have to say that most of the gaps match those that McConnell has identified. My guess is that a good portion of my fellow software developers weren't as lucky.

Instead, I prefer Scrum. This agile methodology advocates short release cycles with an emphasis on locking in a set of change requests every 30 days so that developers can focus on what they're doing. The relatively short period also gives business owners the opportunity to change course and not feel like they're locked in to a large chunk of development that isn't going to meet their needs.

I would, however, borrow XP's ideals of building the simplest thing possible that solves the current problem and to not try and anticipate future needs. And I'm also a proponent of refactoring when it makes sense to do so which is also an element of XP.

And equally scary to both IT professionals and business-types is this statement, "Gartner predicts that by 2010, six out of ten IT professionals will assume business-facing roles." Can you imagine 60% of the your company's IT team interacting DIRECTLY with the business folks in your organization? That's going to be a very interesting transition for some people.

So why does Gartner predict this shift? It comes down to the bottom-line. "With versatilists on staff, business and service providers can stretch their personnel budgets further than they could with specialists." It's hard to argue with that kind of logic. Labor is the largest expense for most companies so why not get someone with the skills of two people assuming you can find them. If Gartner's prediction turns out to be true, code jockeys are soon in for another surprise just after finally adjusting to the tech bubble burst. Now is probably a good time to look for a niche if you haven't already been moving in this direction. Here are the 4 areas of IT that Gartner has identified. If you're in IT, you might want to identify where you fit in today and where you want to be tomorrow.

1. Technology infrastructure and services. Opportunities in technology infrastructure and services, the foundation of the IT profession, will grow in service, hardware and software vendors-many in developing economies-and wane in user companies. Network design will remain strong everywhere.

2. Information design and management. Business intelligence, online consumer services, work enhancement initiatives, search-and-retrieval practices and collaboration all will grow in user companies, systems integrators and consulting companies. Linguistics, language skills, business and cultural knowledge, and knowledge management will be fertile ground.

3. Process design and management. IT professionals can look at process opportunities from three angles: competitive business processes, design of process automation and operational processes. The first will be the "sweet spot" for companies; the second, for software vendors; the third, for outsourcing vendors.

4. Relationship and sourcing management. Far removed from the traditional skills that IT professionals pursue, relationship and sourcing management will gain ground, demanding strengths in managing intangibles and managing geographically distributed parties with different work outcomes and cultures.

Given your work in SEO, I shouldn't be surprised that your site was returned in Google's top 20 responses to my search of "Project management methodologies", but I'm very glad that it did.

I studied IT at college (or Uni as us Brits call it) at the same time as you and have followed a similar career though I am more a business analyst than a project manager.

However, following a nice break from contracting I am back and looking for my next contract here in London and would like to tell you that your site has inspired me!

I was similarly inspired six years ago by a colleague and now good friend of mine who had his CV on the web and told me I should do the same. I duly did and their it has sat gathering electronic dust between infrequent updates.

Seeing your site has been a wake up call. As I, in a way, represent the IT industry, I could do a lot more to both keep my skills up-to-date and promote myself. While my MS Word html file might not become the swish, professional looking website that you have, your standard is a good one to aim for.

You've got a great site (I presume you built it) and one I hope that I can learn from.

Regards,

Crisp

My guess is that training has little ROI because:

• Employees that look for training opportunities are also looking to advance up the corporate ladder. If they feel they aren't moving up fast enough, they'll move to other companies where the training can be pitched as experience.
• Some offsite training programs are used as mini-vacations. They're held in areas with good climates or in resorts that offer a lot of extra-curricular activities. Employees that attend for these reasons are probably not looking for ways to apply their training.
• It's hard to find training that can be applied directly in the real-world. There's a lot of theory that should work, but is difficult to implement in departments or companies that have their ways set in stone. Thus, newly trained employees get frustrated and give up on their efforts to apply their training.

The one piece of good news in the CIO Magazine article is that some positions are still considered very important to CIOs: business analysts, system architects, key programmers, and project managers. I, of course, like that last one.

McConnell has recently written another book on software development. This book, Professional Software Development, is actually a revised and updated version of After the Gold Rush. In Professional Software Development, McConnell examines what's needed to transform the software development industry in to a true profession. McConnell first cites legal precedents to describe the qualities of a profession:

1. A requirement for extensive learning and training
2. A code of ethics imposing standards higher than those normally tolerated in the marketplace
3. A disciplinary system for professionals who breach the code
4. A primary emphasis on social responsibility over strictly individual gain, and a corresponding duty of its members to behave as members of a disciplined and honorable profession.
5. A prerequisite of a license prior to admission to practice

I'm particularly interested in items 3 and 5. I've seen too many in the software field behave in appropriate ways and I have to assume that such behavior is having a negative impact on the industry as a whole. It would be great, at least in theory, to make people accountable for their actions.

Also, requiring that people obtain a license would have the immediate effect of eliminating the not so motivated and not so knowledgeable people who got in to software development without even trying or perhaps to just take advantage of the lucrative bubble that existed a few years ago.

Both of these items, if implemented properly, would elevate the industry and bring it closer to being a respectable profession. I'd like to see the licensing requirement implemented first. I think it's probably the easiest of the items to accomplish. Finding a way to fairly discipline those that breach the code of conduct would be much more difficult.

The process for using BrowserShots is as follows:

1. Go to the BrowserShots site
2. Type in a URL
3. Select the web browsers of interest
4. Set additional options such as screen depth, resolution, JavaScript support etc.
5. Click Submit
6. Wait a bit and then view your screenshots

As good as the system is, it still put up some roadblocks that have annoyed me ever since using it. The biggest roadblock is that the BrowserShots doesn't remember any of the options I've selected. And in all likelihood you're going to want to test using the same options repeatedly which means constantly checking and unchecking dozens of check boxes and selecting options from the drop-down boxes. Fortunately, I've come up with a quick shortcut too all of this.

Here are the instructions to make streamline BrowserShots:

1. Go to BrowserShots.org
2. Use your browser's Save As option to save a copy of the page to your hard drive
3. Open the HTML file yoe just saved in a text editor
4. Search for this code: action="/" and replace with action="http://browsershots.org/"
5. Replace all occurrences of checked="checked" with a space
6. Replace all occurrences of selected="selected" with with a space
7. Go through the source and look for check boxes you want to set. For example, if I wanted FireFox 3.0 on Windows I would change:

   <input type="checkbox" name="windows_firefox_3_0" id="id_windows_firefox_3_0" />

   to

   <input checked="checked" type="checkbox" name="windows_firefox_3_0" id="id_windows_firefox_3_0" />


8. 8. Go through the source and look for drop-down boxes you want to set. For example, if I wanted a screen width of 1024 pixels I would change:

   <option value="1024">1024 pixels wide</option>

   to

   <option value="1024" selected="selected">1024 pixels wide</option>

9. Save your file.
10. Load the saved file into a web browser. You should see all of the options you want already selected so you're good to go!

The main reason behind pulling the plug on a project is to divert the project resources to something else. The problem is that most companies don't have a process for shutting down a project. There's nothing in place to review the merits of a project once it has begun and nothing to describe the process of getting the management approval to stop work. This situation can be remedied by creating a list of termination conditions before getting too far in to the project work. Of course, what goes on to this list is going to vary depending on the project.

One of the easier measures to use in determining whether a project is worth continuing is cost. If the estimated cost of a project balloons such that it can't possibly achieve a positive ROI, then there's probably no reason to continue. Another situation worth considering is the loss of project sponsor interest. This can be a sign that the strategic benefits originally associated with the project have, for one reason or another, passed. The only thing keeping the project going is momentum which is hardly a good reason. Yet another example is the loss of critical expertise. Although rare, it is possible to lose enough knowledge on smaller projects such that it no longer makes sense to attempt completion.

It's important to acknowledge that a canceled project doesn't equate to a failed project. Many of the reasons, such as external market forces, are entirely out of the control of the project team so it hardly makes sense to hold them accountable. On the other hand, a project that isn't canceled in time and is instead allowed to waste resources for a long time before it is finally canceled should be considered a failure. This is an important distinction because it will encourage the project team to examine their projects with a critical eye.

Throughout all of this it isn't the project manager's responsibility to cancel the project. In fact, in most companies the project manager doesn't even have the authority to cancel a project. Instead, the project manager is responsible for providing factual and objective information to management along with a recommendation. And of course, the project manager is then tasked with following the project closing procedures or continuing the project as determined by the project team.

Daniel Kemph's issue with me was with how I used content from his resume elsewhere on this site as a sample of a business analyst resume. I know that a lot of people get hung up on resume writing so I figured some real-world samples that have been anonymized would be good starting points. My resume is also on this site and displayed quite prominently so no alarms went of when I posted the samples.

In Daniel Kemph's case, the version of the resume is 4+ years old, but somehow he found it and it appears that I didn't anonymize the information sufficiently such that he was able to identify the content as being based on his resume. I have to take the blame for a shoddy job in this case. Ignoring that for a moment, what's someone like Daniel to do? Reaching out to the webmaster seems like a good start, although there's an argument to be made about whether to be friendly or not. Daniel chose to not be. Here's his e-mail:

"You need to remove my resume as your 'sample' immediately. I have never sent my resume to you and am refuting your usage of it. I won't hesitate to take legal action against you as I am able to prove, without a doubt in a court of law, that the sample resume you've posted is mine."

As I wrote earlier, Daniel Kemph submitted his resume by his own volition in 2004 (I still have the original e-mail). He also submitted his resume for a business analyst position which the submission form didn't mention existed. So I'd argue that Daniel is a little to blame. More to the point, was my paraphrasing of his resume in a sample an example of plagiarism? Does he have the right to ask me to take it down? I chose to explore the situation further by agreeing to Daniel's request, but with big-ego undertones to see what sort of response I'd get. Here's what I wrote:

"On the submission form there was no mention about how the resume would be used nor did you restrict its use. In fact, I'm pretty sure you didn't read this particular submission form because it has never asked for business analyst resumes."

"Lastly, I will take some time to better anonymize the resume or replace it entirely with another one since you asked so nicely."

Note that I did agree to correct my mistake with what I had posted, but I put in plenty of bait for Daniel Kemph to bite on. And bite he did…

"If the attorney is a friend and finds your usage to be as offensive as I, then I'm certain he won't have any problems filing papers in a CA court. Later, we'll work out who exactly will have to pay for your poor judgment.

Remove the format and all it's contents now please."

At this point I gave in. I figured there was nothing more I would get from additional e-mails. Of course, I still had to be a smart-a** Sorry Daniel, I just could resist.

"Hmm… Yes. An offended lawyer that is also a friend is indeed scary. I need to start hanging out with a different crowd.

The resume that resembled yours has been removed."

So what's your take? Is using someone's resume (a fairly public document in most case) as the basis for a web page stepping over the line? Should Daniel have been more polite with his initial request?

The capacity for effective organizational change shares many attributes with common sense: a feeling that it is all too uncommon, and lacking in widespread, rational logic. No subject has had more books written about it, yet still been so widely misunderstood and misapplied. The effectiveness of organizational change approaches appear on the surface to have no formula, pattern or framework for repeated success. Even among the purported and often self-styled 'gurus' there is no one practitioner that has been able to maintain a sustained reputation for success in the field. Movements have come and gone; fads have emerged and with equal rapidity faded into the mists of embarrassing memory. We look on them with the same sense of discomfort as the first time we asked someone we 'really liked' out on a date: awkwardly, sweaty-palmed and with the nagging feeling that success, if attained at all, was fleeting and insubstantial.

No question endures more, has been thought of as much, and has been answered with such variance, as of the role of grassroots participation in creating successful, sustained and meaningful organizational change. Do we dictate, or do we facilitate? Is corporate success attained through the brilliant insight and forceful guidance of a select few, or the participation and widespread consensus and commitment of the many? Is it the responsibility of senior management to direct and mandate, or to influence, facilitate and guide?

To look at the industry is to find no easy answers. In a corporate environment that lionizes the blunt and more than ruthless approach of 'Neutron' Jack Welch and 'Chainsaw' Al Dunlop, you have an equal number of proponents of 'servant' leadership, participative decision making and self-managed teams. Both models argue financial, corporate and market valuation successes. Which begs the question of just who is right?

The answer will not be easy. There are too many proponents, too many myths, and too much misguided, untested, yet devoutly believed philosophy for us to emerge from this argument unscathed. Yet the need for an answer is both palpable and growing in importance. Organizations are at a crossroads, with an uncertain path before them: Do they answer to the market? Their customers? Their board members? Their employees? Their conscience?

At a time where the need is greatest, the answers have gone away. In the late '80s we had Total Quality Management. In Search of Excellence. Strategic planning. Peter Drucker. The '90s launched with re-engineering. Tony Robbins. The 7 Habits. Today, every author wants to launch the next fad. Every consultant wants to be the next guru. Every business leader wants to be on the next Fortune cover. Clarity has been replaced with chaos, obfuscation and greed.

In the absence of a clear path forward, a clear mandate of performance, and a clear mechanism to drive organizational change, we stumble from fad to fad, guru to guru, catchphrase to pithy aphorism. All of which suggests that we seek most is participation, involvement, community and involvement. And yet we remove ourselves further from meaningful commitment, participation and attachment. The social contract has been torn up. The man in the grey flannel suit has been replaced by the corporate free agent.

In future posts, we will focus on the models for organizational change, in an attempt to resolve the conundrum of how to secure effective, meaningful and lasting change an organization - from the top, or from the bottom? By executive fiat, or negotiated consensus? What works, and why?

While a definitive answer may yet prove elusive, we will all be better off for at least asking the question and attempting to establish a reasoned insight into the issues, enablers and stumbling blocks of successful change.

The implications are far reaching. Dissatisfaction has emerged as a general state of being: with ourselves, our spouses and families, our organizations and our governments. While the frustration continues to grow, the answers to how change can be achieved and how the will to initiate the process can be crystallized become increasingly elusive.

From the perspective of a project manager, the project starts when they get assigned to it and stops with the completion of whatever it is that they've been tasked with building. Simple and straightforward as far as it goes, but it's also perfectly clear to most readers that there is work that still happens before the project starts and after the project ends. In particular, there is whatever decision making process actually led to the project being initiated and a project manager being appointed, and the later process after a project is done of beginning to use whatever was produced to get the value that the organization desires.

From the perspective of the organization, or of a senior manager, there is therefore a different view of project that starts with idea and ends with realized value. What we have is two very different definitions of project, which have different start and finish points. This is not to say that one definition is right and the other is wrong. Both are important, yet we tend to use the same term of 'project' to describe both. It is the failure to distinguish between these two ideas that leads to enormous misunderstandings in organizations. Not only is it not clear where the project starts or finishes, but there is confusion around who is responsible for what.

To clarify, it helps to separate out for the project manager and for senior management what it is that they are trying to accomplish. The project manager wants to know what they need to get done. The executive wants to get the value out of their investment. Both are necessary. The product that is produced is what allows the value of the investment to be realized. As a result, both are also inextricably intertwined. Yet they represent separate ideas, which means that we need to speak of them and consciously identify them as being different.

To illustrate this distinction, it helps to look at a case study. One example I often use in workshops is an organization that undertook a quality improvement project associated with their billing system. The impetus for the project was a benchmarking study that indicated that there were 5 times as many people in the organization responsible for correcting billing errors than the average for the industry. To bring these numbers in line, the organization initiated a project whose objectives were to reduce billing errors by 95%, which would allow them to redeploy up to 45 people elsewhere in the organization.

The project proceeded forward quite successfully. Tracking their reduction in errors over time, the team eliminated 97% of errors, focusing on the most significant ones first. They delivered on time and under budget. Throughout the project, extensive consultations were made regarding plans to redeploy staff members to more significant, value-added positions. When the project was completed, however, the organization in the middle of intense negotiations with their collective bargaining unit, and chose — in order to avoid a grievance being filed — not to redeploy the staff members. As a result, 50 people were now doing the work of 5, and the organization failed to realize any of the projected savings. It's a sad story, but a true one, and not necessarily out of place in any number of organizations.

When I asked workshop participants whether or not the project was successful, invariably the room was divided along 50-50 lines between those who say 'yes' because the team did what they were supposed to do, and those who say 'no' because the organization failed to realize its investment objectives. Both statements are objectively true, however only one describes project success.

The reality is that the project was successful–more than successful, in fact, in the context of the objectives set for it. Defects were reduced to a greater extent than hoped, and the project delivered under budget. By every objective measure of what the result of the project was to be, the project team delivered. The investment, however, was a failure. Over $1 million of investment was written off, for reasons that had nothing to do with the project. The reason to not redeploy staff was a business choice, made for operational reasons. Not to say that this was a bad decision either — the cost of a grievance could well have been much higher than any projected savings. Yet this was not a project decision, it was an organization decision.

The point here is a simple one — any initiative must be evaluated with respect to both dimensions. Project success evaluates whether or not the process and what was produced as a result of the project — the 'final product' — was successful; in other words, did you get what you had hoped for out of the project, and was it delivered within the allowable envelope of time, cost and resources? Investment success evaluates whether or not you realized value out of getting the final product of the project; in other words, did you get your hoped for return on investment, however that was being measured.

That these concepts get blurred is understandable, but they genuinely define different concepts and therefore must be considered differently. We must objectively understand what the expectations are of both the project success and the investment success. Ideally, we realize both. Where one is realized despite — or at the expense of — the other, it is important to understand the underlying causes. To simply blur the two together, however, is to avoid the need to manage both, and to avoid setting accountability for each where it truly lies.

This simple truth was reinforced for me through a number of recent corporate presentations, in which project managers were being introduced to a new framework for managing projects. While the process that the framework outlines is straightforward, easily understood and readily adapted and scaled to a variety of projects, there was a huge amount of overall resistance to its initial use and adoption. A certain amount of resistance can readily be attributed to any organizational change effort, but the reaction of participants seemed inordinately negative.

It goes without saying that any change will have its negative influences, and certainly this engagement was no different. Given the amount of effort that had gone in to ensuring buy-in, acceptance and validity of the proposed solution, however, the reactions were surprising. There was strong executive support and commitment, extensive consultation from project managers that would use the process, and a comprehensive training and education process had been developed to support staff in understanding the process, their role within it and the commitments and expectations of the organization.

In pursuing the source of this resistance, what became clear was that its source had little to do with the validity of the project management framework itself. In fact, there was almost universal acknowledgment that the framework made sense, provided a great deal of value and was readily adaptable to the wide array of projects the organization undertook. The problem was rooted in the fact that the organization expected improvement in project performance as a result of implementing the framework.

Arguably, it was as desire for improvement in project performance that led the organization to adopt a new project management framework in the first place, so this objective should not on the face of it seem unreasonable. What was of concern was the attainability of this objective given how projects were evaluated, prioritized and selected within the organization. The operating belief in the organization was that by hiring better project managers and establishing better project processes, improved project results were attainable. At the same time, senior management within the organization clearly believed that whatever choices they made regarding the projects that they chose to initiate were fair game — that the decision-making process was separate and distinct from what was required to successfully deliver them.

The concerns expressed by the project managers was a reaction to the fact that a significant number of project problems begin with how projects are dependent upon they are initiated. Decisions made at the outset can have the impact of effectively handicapping a project, short-circuiting the impact of any attempts to apply proper project management. From imposing a solution without a full appreciation of the requirements to fixing the cost budget without any clear appreciation of the actual underlying work that funding must pay for, these constraints — if accepted — can railroad the project team into a situation that is almost certainly destined for failure. While a good project management process, for example, recognizes that progressive refinement of the estimates is appropriate as more information becomes known about the project, imposing a budget can have the net effect of turning the project into an exercise of how much project can be done for a defined amount of money.

While the fact that these decisions get made is certainly important, of more significance is an understanding of why sponsors and executives make them. Possibly the simplest explanation is 'because they can', but that doesn't really speak to the underlying motives that actually leads them to make the decisions they do. All too often, it is for the same optimistic reasons that have plagued projects in the past — the belief that a project should only cost that much, and if only the team tries really hard they can pull it off. In other instances, it may be a consequence of the age-old practice of accommodating the express or perceived wishes of their bosses. It can be a results of believing that creating artificial boundaries is a way of motivating teams to 'think outside of the box'. Sometimes, it comes down to the simple and sadistic pleasure of watching someone squirm — the corporate equivalent of frying ants with a magnifying glass.

What is clear from all of this is that while project management itself continues to mature and improve, the results that projects deliver won't significantly improve unless the full lifecycle of decision making — from initiation at the beginning through to the process of value realization at the end — align to create a consistent, logical and related process of decision making. This article begins a new series that will explore these issues in details. Through it, I hope to be able to inject some much-need rationality into a process that many view as overly irrational. Stay tuned.

The rationale by which project decisions get made varies widely from organization to organization, and is for the vast majority of organizations largely a subjective process. While a few short years ago the linkage between projects and strategy was a much more tenuous one, it is now becoming much more widely recognized that projects are a key means of realizing organizational strategy. The choices we make in terms of the projects that are taken on have a significant influence in defining organizational strategy for the organization.

From the perspective of the PMO, an important consideration here is where and how the process of prioritization occurs in deciding which projects to proceed with. Because prioritization represents the intersection between strategy and one hand and project delivery on the other, a strong case can be made for the PMO managing the prioritization process. This is in fact emerging as one of the key roles that the PMO plays in several organizations I have worked with. Arguably, however, an equally strong argument can be made that prioritization must be managed by the business. Given the growing trend towards the PMO at least playing some role in the prioritization of projects, what emerge as key questions are: a) should this be a role the PMO takes on?; and b) what aspects of the role are most appropriate for the PMO to manage?

The key danger in this role falling to the PMO lies in the fact that a true PMO cannot make decisions on behalf of the business. They can administer the process, facilitate the identification of criteria, and even maintain the records of the decisions that have been made, but they cannot actually make the decisions. What this really reflects is the role of PMO as facilitator, rather than PMO as owner, a theme that has emerged many times in previous columns.
Were the PMO to truly manage the prioritization process, they would in effect be responsible for setting the strategy for the organization, an abdication of the role of the business itself. That said, where many organizations fall down on the business side is on having a process to effectively manage prioritization. Prioritizing and choosing projects all too often devolves into choosing between apples, oranges and kumquats — without a process and objective criteria for prioritization in place, making choices between projects becomes more about a popularity contest than it is about objective decision-making. Looking at executive teams that I have worked with in the past, many have very confidently been able to make effective decisions within the bounds of established evaluation criteria, but have struggled with the wide open question of "what criteria do you need to see demonstrated by a project in order for it to be able to proceed forward?"

What the PMO can do to effectively respond to the challenges described above is to manage the process; to facilitate its definition and use, and to act as a guide in the establishment and application of prioritization criteria. This is a much more strategic role than what many PMOs may do today, but done well represents a significant opportunity for the PMO to be able to add significant value to the project management process — by helping guide the organization in choosing the right projects, the chances for projects to be successful rise exponentially.

To be able to facilitate an organization's prioritization process, there are some fundamental capabilities that the PMO needs to establish or ensure are in place:

• A process for prioritization and approval. One of the most significant challenges in project initiation is understanding how a particular project must be prioritized and approved. For some memorable organizations I have observed, even after 12 months I couldn't objectively tell you up front what a process a specific project would need to go through to get approved. Every project was treated differently, with some flying through the approval process in record time and others that were equally if not more valuable being bogged down with committees, reviews, business cases and consultant reports. For any project of a specific type, size and complexity, your organization should have in place clear guidelines that define what needs to be done to get project approval, and who is responsible for granting that approval.
• Clear criteria for prioritization and project selection. Over and above understanding the approval process, there is a need to define clear and objective criteria of how projects are to be prioritized. Simply put, prioritization criteria are the qualities or attributes that a project needs to have in order to be able to proceed forward now. It defines what aspects a project must demonstrate and support if it is in fact aligned with the strategic plan. Whether the criteria are strategic alignment, risk, resource availability or financial return, the criteria should be defined, understood and able to be evaluated on a consistent basis from project to project.
• An understanding of budget and resource capacity. Prioritization is one thing; the capacity to deliver on your priorities is another. Within any category of projects, there will from year to year be far more projects than there is the financial and resource capacity to deliver those projects. This means understanding the core budget available for projects, and more importantly the resource capacity of the organization to staff them. Resource capacity is particularly challenging simply because so many organizations are lacking the tools to be able to effectively track how much effort is available for project work, and how much of that effort is already committed to initiatives underway.
• Commitment to use the process. Finally, the PMO can only facilitate a process where there is willingness and commitment for the PMO to facilitate the process. Where the organizational commitment isn't there, a process cannot be imposed on the organization. Bottom line, the prioritization of projects is still a business choice, and regardless of how tempting it might be, a process cannot be imposed if the business is not prepared to accept a process. More importantly, commitment to use the process must mean that all projects are subjected to the same prioritization process — if a project is allowed to bypass the process that the rest of the opportunities are required to adhere to, the process will no longer be credible and prioritization will revert to gamesmanship.

There is absolutely a role to be played by the PMO in supporting and facilitating the evaluation and prioritization of projects and opportunities. This role, as discussed above, must be as a facilitator rather than a decision maker. As awareness of the role of projects in delivering strategy continues to grow, however, effective facilitation is the capability that most organizations will need most.

A side effect of this role is the increasing move of the PMO to a role of being a corporate capability, rather than being the province of a single business unit or functional area. PMOs that do not report to a corporate level today will find this role much more difficult to take on, simply because their reporting structure can lead to a perception of conflicts of interest being present. Where a corporate mandate and accountability structure already exists, this role becomes more readily accepted. The value that results is better decisions, better projects, and ideally better project results. Isn't that what the PMO is all about?

While the principles of formal project management have been around for decades in more 'traditional' industries such as engineering and construction, project management as a means of leading information technology, process management and organizational change projects began to be introduced in the early 1990s. It is only since the late 1990s that from an organizational and senior management perspective, it has begun to take root in many companies.

It is this level of organizational awareness that seems to represent the tipping point that separates a tool, technique or approach from being the passionate focus of a small group of knowledgeable practitioners to a widespread but less understood fad. Looking at many of the management trends that have come before — total quality management, re-engineering, Six Sigma, customer relationship management — they have all followed a very similar path. Like televisions shows 'jumping the shark'(a term coined to define a TV series at the point of decline — immortalized when the Fonz jumped a shark in 'Happy Days'), what was valuable and unique ultimately become bland and without content.

At their outset, each of these approaches represented a viable and theoretically useful means of accomplishing some outcome, whether improving processes, optimizing quality practices or increasing the knowledge of overall customer requirements. Rooted in proven, valid and fairly complex practices, they were able to generate significant gains for the companies that invested in understanding, adopting and adapting them to their specific needs. As they were realized, recognition of these successes by other organizations and promotion of the value of the approaches by other consultants led to additional attempts to replicate the original achievements. The first wave of practitioners with a deep level of understanding of how the techniques were customized effectively were followed by a host of 'me too' consultants who saw an emerging opportunity to market their services. Even more companies attempted to mimic the achievement of the early adopters, but success proved more and more elusive until ultimately the fad was discredited as being meaningless hype.

So was it the practices that failed, or was it the practices becoming fads that led to their demise? To a large extent, the problem is both. Any practice, properly applied, is context specific. Just as every company does not have the same organizational structure, accounting system or HR policies as every other one, neither will the same approach to re-engineering, quality or project management work interchangeable from one organization to another. The early successes were based in large part because a considerable effort was expended in trying to figure out what worked, and what didn't, in the specific context of one organization. Organizations attempting to replicate this success took the techniques that worked for the one and tried to duplicate them in the others, regardless of the appropriateness of context. By definition, some would work and others would not — but the further you moved away from the context on which they were based, the less relevant they were.

The nature of fads, however, certainly hastened the descent of these practices into the dustbin of irrelevance. They are appealing by their nature because they have the promise of being a 'silver bullet'. No matter how often we intellectually recognize there are no silver bullets–just hard work–emotionally, we still cling to the hope that one day we might find one. Once a technique becomes a fad, marketing and hype take over. The motive to adopt an approach becomes less and less about the specific results, and more about emulating what others have done to get their results. What gets adopted is the surface appearance of practices, without the underlying rationale, discipline or context necessary to make them work. What companies are left with is an empty shell. This is a little like buying a sports car with no engine; it looks pretty, but it doesn't go very far.

That project management is starting to be view by some as a fad is therefore more than a little disturbing. Clearly, marketing is taking over — the number of conferences and books on the subject are now growing exponentially. While executive teams are recognizing the need to manage projects better, there is often a subconscious — and occasionally overt — expectation that this shouldn't come at the expense of having to be formal and disciplined about anything. When style takes precedence over substance, the demise of a fad cannot be too far behind.

The lesson for project management — and for any discipline — lies in going back to what worked in the beginning. For the organizations that experienced early success, what drove that success was not simply the practices that they landed on. Far more important was the process of experimentation and discovering what did and didn't work for them, that led to the identification of the tools and techniques they kept. We need to embrace the learning and experimentation that leads to understanding of value and context, not simply borrowing and benchmarking from others without giving thought to how what is being borrowed can — or should — be applied. Project management needs to be adopted because it works for us, not our competition or the company down the road. More importantly, we need to take the time to truly understand how to make it work for us. There are no silver bullets here. But there just might be a silver lining.

In the world of organizations, all work can be divided into two categories: you are either running the business or you are changing the business. The act of running the business is governed by a host of well defined processes, techniques and disciplines collectively described as operations management. If you are changing the business, you are doing projects. What is frustrating for many senior managers, and some project managers, is that the process of changing the business is often so poorly managed. In many instances, change efforts are not even identified as being projects. Responsibility for these 'accidental projects' is assumed by management teams who don't see them as such, and may not even recognize that the discipline of project management exists and could provide meaningful support.

Nowhere is this more true than in the development and articulation of strategic plans. The real role of a strategic plan is nothing less than establishing the blueprint for changing the business. Practically speaking, it should identify the activities and the full scope of effort necessary to manage the changes that are expected - from the creation of new products or markets to the improvement of productivity or the establishment of production targets. To validate this, think of your own organization: if you were satisfied with the same quality, productivity and cost structure, and were to continue to provide the same products and services in the same quantities and at the same price to the same customers, you wouldn't need a strategic plan. In a nutshell, the strategic plan defines what is going to be different, this year or for the next few years.

The implication of this statement is that all projects should be aligned with the strategic plan, and the strategic plan should articulate all projects that are to be done within the organization. Whether establishing new locations, launching new products, entering new markets or making changes to productivity and quality, all of these changes should derive from the strategic plan. So too should all of the smaller changes - whether optimizing production lines, improving process quality, enhancing information systems or establishing a relationship with a new customer. Each of these efforts is a project, and should be managed as such, and any project being undertaken should clearly align with and support the strategic plan.

Now, there are those that will argue that you can't plan all of these activities up front, and as such it is inappropriate for them all to be defined in the strategic plan. To a certain extent, this is true - many initiatives can not be identified during a formalized annual planning cycle, and will emerge throughout the course of the business year. This does not mean that these efforts should not align with the overall goals and direction of the strategic plan, and that this alignment should not be formally validated prior to initiating the project.

This is also not to say that the senior management team must therefore review, prioritize and approve each and every project prior to its initiation, no matter how small. The best strategic planning processes have multiple layers of definition, from the overarching corporate objectives through to individual business unit and departmental plans. The key emphasis is on ensuring alignment from the organization to the division to the department. While each department will define their own plans and review them with their immediate management teams, each is still responsible for running their operation and overseeing the projects they are responsible for. While senior management may not formally review and approve every departmental or divisional initiative, there should at least be a level of auditability that verifies each project aligns with the rest of the organization.

The importance of this alignment has been driven home through consulting with several customers around their business planning and prioritization processes. What these engagements have illustrated is that in the majority of companies only a small percentage of projects are actually visible at a senior management level. These projects are usually corporate in nature, having a far-reaching impact on the organization's health and future well-being and often representing a significant investment of corporate resources. What is unique about these projects is that they often represent a significant majority of financial investment in projects - up to 75% of total project expenditures in some organizations - while representing a much smaller percentage of overall staff effort. The majority of staff hours, again typically between 60% and 75%, are actually spent on projects that senior management is not even aware of. Given the significant degree of human capital associated with these projects, organizations have a responsibility to ensure that it is effectively managed.

Once we recognize that the work of strategic plans is really project work, the reason for many organizations failing to realize their strategic goals also begins to become clear. The failure rates for projects continue to be quite high, even where formal project management is being used - in some organizations, as much as 70% or 80%. When initiatives are being managed without the benefit of formal project management, the failure rates are even higher. We need to start making better choices about how we realize the objectives of our strategic plans, and to recognize and approach the projects they define using formal management techniques.

More importantly, however, we need to recognize that projects are a threat to the operational status quo -operations management is designed to ensure consistency and repeatability, and to the greatest degree possible minimize variation. By definition, projects introduce change into operational processes. They introduce variation, and certainly at the outset will have a detrimental effect on consistency and repeatability, until the new mode of operations can be embraced and adopted. As a result, there tends to be a strong and innate opposition to projects, and often very little enthusiasm for supporting them.

To be effective, organizations need to have far greater alignment between projects, operations and strategy-making. We need to make better choices about the strategies we adopt, and the projects that result from them. We need to ensure that the projects we are undertaking do in fact align with the strategic choices of the organization. And we need to better manage the operational impacts that result from the projects we undertake. Only then can will the work of organizations be truly aligned.

For most organizations today, strategic planning has a bad rap. A well deserved, honestly earned bad rap, but a bad rap nonetheless. In today's world, strategy is viewed as being essential while strategic planning is seen as dispensable. Resolving this dichotomy will be one of the key deciding factors in the success or failure of organizations in the coming years.

What often passes for strategy today would more appropriately be described as 'vision', if that word itself hadn't been drug through the mud of a thousand facilitated team-building sessions. It tends to be a fuzzy, intuitive, gut-level sense of where the organization will be a few years out, rather than any practical and meaningful framework. There is no conscious choice made about what will be done or how that future will be realized, just an earnest and slightly wishful belief that if we all hope hard enough and pull together then the future we desire will be ours.

The antithesis of this view is mired in incrementalism, rooted in a view that the future will be much like today, just bigger. The debate is not over what the future will be, but in how much of that future market share our organization will have or how much growth we will realize over our current base. It is this belief in growth for growth's sake that enables otherwise sane individuals to believe that 50% growth is attainable in perpetuity. Debates rage over determining what growth rate accurately reflects the future, with positions dug in and ardently defended over individual percentage points. Once the dust settles, the 'business plans' are updated to reflect the new sales, performance or growth targets, and the organization once again goes back to whatever else it was doing.

The problem with both of these extremes, apart from encompassing the majority of what passes as strategic planning today, is that they are in no way actually related to strategy. According to Merriam-Webster, the word "strategy" can be defined as "a careful plan or method; the art of devising or employing plans or stratagems toward a goal". In other words, strategies are a statement of how we are going to get there from here, not what "there" looks like. Setting a goal, whether that goal is a new vision of what the organization can be, or an incremental evolution of how we would like to grow and evolve, is merely the first step. It isn't the easiest step, by any stretch, but it is only the first. Once the goal is arrived at, strategy is what in fact determines how we will accomplish that goal.

At this point, you may well be squirming in frustration at this definition of strategy, or nodding your head in recognition - of the problems, and of the issues. A very, very few will be agreeing with the definition, and doing so because what I've described is how they already approach strategy. This is unfortunate; not because they agree, but because there are in fact so few who embrace true strategic planning. What is fascinating are the barriers that get built up in defence of strategy as it is applied - or not applied - in organizations. As a word, 'strategy' becomes an ideologically loaded term that brooks no compromise or challenge. Strategy becomes not a process of defining a path to the future so much as it becomes faith that a path will be defined, and that is not our place to question that path or the vision that defines it.

The reality is that questioning the vision, and questioning the path forward, are essential - questioning is in fact an inherent and necessary element in strategic planning, just as it is in project management. What is essential to developing effective strategy is the process of discovery, not what the answer should be at the end of the day. The process allows us to define why we are choosing a path, not ensuring what the right path really is. If we know why we are pursuing a strategy forward, then we also know what we must do to adapt the strategy when our plans do not unfold as we expect them to.

It is also essential that we recognize our strategies and plans will change. We do not plan because we expect the future to unfold in precisely that manner - this is in fact the source of the problems associated with the 'outcome'-based approaches we discussed earlier. Setting a target without a plan is a recipe for failure. Setting a plan to attain a target without allowing for flexibility of the plan is not much better. Setting a plan that recognizes that actual performance will vary, and allowing for the flexibility to respond to those changes as required, is essential.

To quote Dwight D. Eisenhower, "In preparing for battle I have always found that plans are useless, but planning is indispensable." It is the act of planning that allows us to prepare, to be able to respond, and therefore to maximize the probability of actually attaining our goals. Strategic plans are the framework within which the process of discovery can be realized, and out of which the work going forward can be defined.

The reason that this truth often goes unstated is worthy of special recognition. In many - if not most - cases, the management team that ultimately has the greatest difficulty in coming to terms with the nature of the change is frequently the same management team sponsoring the effort in the first place. Paradoxical? Perhaps, but there are some clear drivers of why this is so.

Let's start with the nature of performance measurement implementations. The underlying rationale is to clearly understand, manage and improve the fundamental performance of the organization. The driver of performance measurement is to quantifiably make visible the key performance drivers of the organization, and create a clear sense of manageability. Candidate measures include productivity, quality, cycle time - the list is as long and as varied as there are candidate organizations.

As I have pointed out in other columns, measurement is personal. One of the key benefits - and one of the fundamental drivers that should in all instances be present - is a clear identification of individual contribution. What impact have I had on the organization? How much revenue have I generated? How many defects have I eliminated? How much has my productivity improved?

Let's deal with the first one: How much money did I make for the company today? Imagine, for example, that you are a service technician, and that for each call you make the company receives $100 in revenue. Make ten calls in a day, and you have contributed $1,000 to the bottom line of your organization. A department of 10 technicians, each performing at the same level, contributes $10,000 to the bottom line each and every day. An easy measure to determine.

So how about the manager of that department? How much revenue did they generate for the company that day? You can't keep claiming the same contribution to the bottom line at each progressive stage up the org chart. The benefits occur once, and once only. This begins to illustrate some of the problems managers have in accepting performance measurement as a concept; those that sponsor it fear that the measures will reflect poorly on them, even if they themselves perceive that they provide a valuable - or essential - function. As such, resistance at a fundamental, personal level is virtually guaranteed.

Part of the problem we are encountering is one of a clear understanding of role. Managers, by their nature, rarely produce direct revenue for the organization. The further you travel up the organizational hierarchy, the more abstract this problem becomes. The logic is simple: the front line is where the rubber meets the road, and where true revenue is generated; the further you are from the front line, the more removed your direct impact on revenue generation.

The key word here is direct. What is being missed in the discussion is that the manager's role is most often an indirect one. The role should be one of leadership: managing costs, improving performance and minimizing defects; all of which are impacts that are felt over the long term. Given these aspects of the role, however, there is a clearly defined opportunity to make a significant impact to the organization, and a measurable one at that. Unfortunately, many managers choose to ignore the value of indirect benefits, or believe that the organization does not perceive them to be sufficiently tangible.

In many cases, managers also find themselves in positions where they are constantly supervising, managing expectations, fighting fires, and dealing with issues and problems. Those who see this as their role are the ones that display the greatest resistance to the concept of introducing performance measures, and with obvious reasons. There is no direct value being created - the process is barely being managed, let alone improved. A focus on improving the process and driving accountability to those directly responsible for execution would eliminate a great deal of churn. The challenge comes when a manager enjoys the fire fighter mentality, and has no desire to improve the process as it diminishes their personal sense of value and worth.
At the end of the day, the argument answers itself. For organizations that seek to improve, performance measurement provides the framework to put the levers of control in the hands of those that truly need them, and of necessity highlights and encourages the elimination of waste, inefficiency and ineffectiveness. At all levels of the organization.
You just have to want it badly enough.

To successfully use a word processor requires a number of skills. Familiarity with a computer and its operating system is a given. An understanding of the principles of the program, and what buttons do what, also has value. More important, though, is the understanding of the principles of words on a page, and the thought process behind creating them. Which means that the fundamental principles of English are essential: grasping paragraph and sentence structure, intuiting subject and object agreement, and knowing not to split your infinitives (the Oxford dictionary notwithstanding) is a fundamental pre-requisite in successfully using a word processor.

Fortunately for Microsoft et al, the majority of people that purchase their word processors have been trained in the nuances of the English language since Kindergarten or earlier. The appreciation of the printed word is innate, as is the metaphor of word processor as electronic typewriter. When someone fires up their brand new word processor, they're way ahead of the game conceptually; familiarity is a technical exercise of understanding the buttons, not the concepts.

Unfortunately, our ready understanding of the concepts of word processors, spreadsheets and the like create an unreasonable expectation around the use and usability of project management tools. In point of fact, project management software is itself a misnomer. The tool that can manage a project doesn't exist, although there is an extensive array of project administration tools available.

What is important to understand here is the distinction between tools and process: process is how you accomplish your goals; the tools just make it easier. While the process of travel will tell you how to get from point A to point B, a car simply becomes a much more efficient tool than your feet in getting there. But the car can't travel on its own; it needs someone to guide it who understands the process, the goal and the desired outcome.

The promise of automation is not that computers will do our work for us; it is that computers will allow us to do our work faster, more efficiently and more accurately. We are still integral to the process. The best project managers are those that understand the process of project management well enough that they can execute it with no automated support whatsoever. Which isn't to say you would want to, necessarily; it just isn't efficient. But if you don't understand the process you are trying to execute, there is no amount of automation that can help you get there from here.

Project software is designed to make administration easy. It cannot make management decisions;