Customer Success with Microsoft Dynamics Sure Step

Chapter 4. Managing Projects

In the previous chapters, you examined solution selling, driving due diligence concepts, and solution envisioning with Sure Step. This chapter will walk you through the fascinating discipline of managing projects. The field of project management is emerging because quality has become a competitive instrument over the years. The Project Management Institute (PMI) defines project management as the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Being a project manager in charge of software implementation projects is a challenging and demanding responsibility. Good project managers combine various skills in a balanced way. They need to bring leadership, communication, negotiation, problem solving, and influencing capabilities into practice in a unique and temporary environment. And when things go wrong, project managers usually find themselves in the eye of the storm. Nevertheless, managing projects brings great rewards. Successfully implementing business solutions implies that your customer organization will benefit from more efficiency in its daily routines because of your team's effort and quality. At the same time, you create and manage a context in which consultants can realize their professional ambitions.

In this chapter you will learn about:

· Projects and project management

· The four pillars of project success

· Project management essentials

· Project management adoption

· The indispensable organizational benefits of project management

About projects and project management

In this section, we will discuss and argue against some widespread resistance to project management and provide you with food for thought on topics such as the need and options for project management.

Myths and resistance

We need to grant the skeptics some credit for their stiff resistance. Resistance to project management is omnipresent and sometimes embedded in hard-to-shatter myths. The onus of proof rests with the plaintiff, and so we need to plead the project management cause for every assignment, which is a glaring contrast to the tolerance for the unstructured approach. Now what kind of resistance do we face? The opinion that project management has a lot of overhead is widespread. At the same time, it is often seen as an obstacle to flexibility. Many people consider project management as the theorizer's way of doing things diametrically opposed to the management's prime directive of getting things done.

Project management is also labeled as unsalable, like dead stock. These kinds of arguments make you think twice before shouting your project management ambitions from the rooftops. But how strong is the skeptics' case?

Is project management an overhead?

What is overhead? From a cost-accounting perspective, overhead costs are the costs incurred for operating a business but that do not generate revenue or profits directly. Typical overhead costs include those for accounting, advertising, depreciation, insurance, interest, legal fees, rent, repairs, supplies, taxes, telephone bills, travel, and utilities costs. Using this logic, the question of whether or not expense on project management is an overhead leads to another question: do we send invoices to our customers for the project management services that we provide? However, is this the crucial question? According to this line of reasoning, we should categorize our sales costs as an overhead and should not be invoicing the services of our sales teams. If we were to partly invoice our project managers, does this make the overhead question redundant?

When the skeptics refer to project management as an overhead cost, they often think about a mountain of papers and quite a few procedures and administrative tasks associated with the project management discipline. This criticism can be legitimate when their project management practice is not scaled to the size and complexity of the projects or to their organizational structure. Ignorance is usually at the basis of these failing project management procedures.

To answer the overhead question, we need to assess the benefits of our project management practice. Does it contribute to our project's profit and quality? Does it add value to our customers and team? If the answer to these two questions is positive, it is clearly not an overhead. If you cannot extract these benefits, your project management expenditure may be labeled as an overhead. Project management is what you and your organization make of it, and it can either turn into an overhead or a value-added service.

So when the skeptics cry out that project management adds to overhead, they are probably right. But it tells you more about their project management practice than about project management in general.

Is project management an obstacle to flexibility?

You often meet people who claim to support the project management practice, but they instantly add that they fear the impact on the organizational flexibility. They think that project management procedures will decrease their ability to respond to unpredicted changes, and it doesn't take long before their reasoning sets project management against a pragmatic approach. So, isn't project management concerned with practical matters? Do we lose the ability to change, and does project management stand in the way of progress in our projects? These are the questions to be answered when testing the accuracy of this proposition.

The project management discipline would be in great difficulty if this were all true. Who on earth would even consider implementing a project management practice knowing that it will paralyze the organization's effectiveness? Are the millions of project management practitioners laboring under a misapprehension? This looks like an untenable supposition.

Mostly, this aversion towards project management finds its breeding ground in the inability to separate the essentials from the side issues. People struggling with this dilemma overemphasize the importance of all the described project management tools, documents, and steps of a methodology. They spend too much time administering and describing the project, losing valuable time for the real management of the project and its practical matters. A bureaucratic vision of project management causes a contrast with the "let's just get on with the job" approach.

Good project management practice is all about managing change, practical matters, and flexibility. By keeping it result driven, lean, and mean, it will empower you to make the project happen. A good project manager is not a bureaucrat, but is a tightrope walker, balancing the need for administration, steps, and tools in each project. Now that's easier said than done, and it takes a seasoned project manager with thorough knowledge of the project management discipline to realize the structured flexibility. Although unskilled and inexperienced project managers tend to get a hold of the rigid procedures, company executives cannot go scot-free either when speaking about obstacles to flexibility. They are responsible for the company's culture, and this culture represents the limit of what is achievable for the company.

Is project management unsalable?

The previous chapter, which is about solution selling, will probably enable you to answer this question by yourself. A project management practice that unleashes value and benefits for the customer must be salable. If you can't get it sold, you struggle to sell the value of your methodology and/or you cannot convince the customer of the need for it. This can be related to the intrinsic values of your methodology or to a failing sales process. We are used to selling our software, business consultancy services, and development expertise, but how familiar are we with selling a project management service? Do we have a good selling strategy in place for valuing this type of service? If you want to get project management sold, it must be a real element of your adaptable value proposition, necessary for good bridge selling. Your customer or prospect may not be familiar with the landscape of implementation projects and the need for project management, and they may be nervous or even frightened to traverse it. Your value proposition for project management services needs to be flexible and adaptable to variations in each opportunity. A notable fact is that those who claim not to be able to sell project management have no adaptable value proposition for it, and yet price their project managers as the most expensive individuals on the team. In this way, they create their own obstacles.

Why project management?

This is the key question that needs to be asked before we even consider implementing a project. A good project management practice needs to address the issues that we want to see resolved or improved. In general, there is only one common goal that needs to be realized: to make projects profitable and successful. You want and need to make profit from your projects, and at the same time, deliver value to your customers as expected. This is a matter of economic survival.

You must have heard this before, but did you give it some thought? Delivering software projects that lose money is fairly easy. All you need is customer buy-in, some resources, and there you go. Some people don't even realize that their projects weren't lucrative until the end of the fiscal year, when accountants call executives to account. A project is a synonym for risk, and if you want to realize the essential goals of profitability and customer satisfaction, you need to manage the risks. This is why you need project management, not as a side issue, but as an essential vehicle for your project's business.

We now know that you need project management because your projects need to be delivered on time and within budget and scope. But are these goals SMART (specific, measurable, attainable, relevant, and time-bound) enough? If you want a project management practice that is pragmatic, you need to define pragmatic goals as well. What does it need to succeed in your organization and your specific projects? How can it be valuable to your people and your customers? Be specific about it. Most companies have a set of specific metrics for their sales, marketing, finance, and operational systems and services based on well-considered and specific objectives. If projects are the essential component of your services business, you need to have these objectives as well for your project management practice. Without them, it's a hard road to improve on your project's profit and customer satisfaction. Yes, "on time" and "within budget" is measurable, but can you measure "within scope" and "meets quality expectations" without set specifications? How is your current project management practice contributing to these goals? What would be the effect if your current project management procedures were put on hold? How can you improve your project management practice in the future, or will you still be working with exactly the same procedures in a few years? There's room for smarter objectives if you are really seeking a value-adding project management practice. So, before you start beating your brains out on how to implement a project management methodology, start defining why you need it and what it needs to achieve. Now, where do you start?

Of course it is not so easy to define how your project management practice must contribute to your company's success. It demands a strong vision on your service delivery strategy, your company's strengths and weaknesses, your customer portfolio and sector, and your employee mix and project history. Your project management goals need to be embedded in this context, and at the same time, they need to be very specific in different disciplines. You can start by developing a breakdown of areas where you will define objectives to be realized and measured.

A good starting point could be the nine knowledge areas as described in the Project Management Body of Knowledge (PMBOK) and adopted within Sure Step. They are as follows:

· Project Integration Management

· Project Scope Management

· Project Time Management

· Project Cost Management

· Project Quality Management

· Project Human Resource Management

· Project Communications Management

· Project Risk Management

· Project Procurement Management

Take the preceding knowledge areas as categories for your objectives and prioritize them. Which areas match with your SWOT (strengths, weaknesses, opportunities, and threats) analysis outcome and align with your service strategy key points? Envision within each of these categories what will help your organization to improve your service. What are the known issues and what needs to be resolved? What tools and procedures do you need to achieve that and what will be the resulting business improvements? Who will benefit from it and to what extent? This is just an example of a breakdown for your objectives. You can make it in any kind of way as long as it is valuable for you and your company. The key point is that you need to know exactly why you need project management if you want to adapt to a helpful project methodology.

The alternative

Let's assume that you want to deliver your projects without a standard project management methodology. Where would you end up? One of the first symptoms is that most of your colleagues will fill in their project roles in their own way. Each consultant, developer, and project manager will have their own tools, templates, steps, quality standards, and even their own jargon. You will find it difficult to work in harmony with your colleagues as it is hard to envision what and how they will deliver. How can you manage the team's activities and deliverables in a proactive way? How will the team members know what is expected from them? Different project managers in your company may set completely different objectives, quality standards, and deliverables in their projects.

Imagine that you are engaged as a consultant or developer, working on two projects with various project managers expressing completely different expectations in terms of what and how to deliver. How difficult and inefficient is that? How can you communicate to your customer what they may expect?

With such a modus operandi, the success of your projects will be a gamble. Some projects will turn out to be successes, while others get stuck in general discontent. As a company, you leave the probability of your company's project success entirely to individuals and there will be no way to improve your overall quality and profit in a structured way. Companies working in this way usually see only one way to improve their quality: by replacing resources. They find comfort in the idea that a few people were responsible for the project's failure and reassure themselves that with other resources this could not have happened. It usually doesn't take long before they are facing the same problems all over again in a new project. Chaos is ruling in these companies and it is discouraging to all involved.

Some companies associate formal project management usage with compensation. If the customer is willing to pay for these services on their engagements, the implementation will be guided by a project manager. In these cases, they make the deployment of project management principles on their projects dependent on the ability to sell the project and on the customer's ability to understand the need for project management. Failing to get a customer budget for project management implies an unmanaged implementation. You certainly know the cases where a sales manager communicates that there is little (if any) budget for project management. Then what happens? It's a remarkable fact that, in these circumstances, a project manager will be assigned. No budget means lacking project management, but a project manager is assigned nevertheless. Who wants to be in this person's shoes? Usually, a seasoned consultant with a track record of good product experience gets the honor of managing this assignment. This person needs to be the doer as well as the manager at the same time, requiring a complex straddle that is hard to perform even when a significant number of days are available for the task. Now this poor project manager needs to go through this exercise, knowing that there is no official project management time available. Don't forget that risks are not dependent on reward. Our seasoned product specialist will face the same level of risks as when a significant project management budget would have been available. In most of these cases, no clear and formal agreements are made in terms of the project risks. The customer will transfer the risk to the vendor wherever possible, and you will be forced to deliver in line with the expectations.

What kind of outcome can we expect? Along with the regular application consultant's task, our poor seasoned application consultant fulfilling the project manager's role will probably be queuing numerous internal and customer meetings, negotiations, additional analysis activities, scope changes, planning, scheduling, and so on.

By now, our consultant is up to his neck in work and cannot focus enough on the regular consultant's tasks. This will bring about quality issues, causing even more meetings, negotiations, and rework. To get out of this vicious circle, you probably need a mix of sales along with project management skills and guidance. So in the end, you did work for which you didn't have any budgeting and excluded as a service to your customer. Unfortunately, it was not really efficient or proactive, and it ended up costing much more than what a well thought-out project management job would have cost if one had been in place. In the best case scenario, the organization is aware of this extra time spent on the specific project, but in many cases, people try to cover up by creative reporting in their timesheets. In that case, you will probably notice by the end of the fiscal year that your projects were not as lucrative as expected, which is a not-so-nice surprise.

The customers don't benefit from this scenario either. They started an Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) implementation to improve their business processes and to empower their people with efficient tools, enabling them to be more effective in their jobs. Ending up with numerous meetings, dead-end discussions, and a grumbling workforce is far away from the envisioned objectives. They should be made aware about the risk factor as an essential element of implementation projects. Customers have a distinct interest in the positive outcome of the project and must accept the necessity of project management.

So, what's really the alternative? Don't forget that risks are not dependent on reward.

Using our own methodology

Full marks go to those companies that invested time to develop their own implementation methodology. It is not obvious to envision a quality strategy for your projects, not to mention the work involved in transferring this vision into a workable set of procedures, guidance, and tools while encouraging the organization to adapt to it. However, it is a joy to see this rough journey guiding an entire company to project success, profitability, and satisfied customers and employees. For these partners, the implemented, structured project management methodology will be the starting point and key instrument for continuous improvements and the center of their competitive advantage.

In all fairness, we need to add that not all companies who claim to have a project methodology of their own really do have one. Some are aware, while others just can't see that what they have in place is not adding any value and can't be considered project management methodology. Let's focus on this last category—those who think they have a solid methodology. Why are they on the wrong track? The first thing to check is who is really using it in the organization. If nobody is using the methodology, it is of no value, no matter how good the intrinsic value is. If your methodology exists only on paper and in presentations, it doesn't really exist. How can you know? This is a simple question with a simple answer: by checking or (even better) by controlling. Questions such as "Are you using the methodology?" will not get you the answers. You need to dig a bit deeper by inspecting on a regular basis who is using the methodology and what parts are they using. This quality control will reveal the real usage of your methodology.

A second question that you need to ask is what value your methodology delivers. Does it really make a difference? What is the intrinsic value of it? Sometimes it looks as if some people are content with the phase-based approach. "As long as we have defined phases, we are on the safe side" is their reasoning. The phases symbolize the company's know-how in project matters and guarantee that not all work is done at the same time. They indicate that planning and milestones are crucial elements of the company's implementation approach. This methodology can be summarized in three words: phases, planning, and milestones. We all know that these are valuable elements of a project management methodology, but they don't make up the complete value offering of a methodology. You cannot conclude that you have a house when only the shell of your building has been realized. At this stage, the construction does not yet provide you with the functions that we expect from a house. It does not protect, and it cannot give any comfort yet. An approach including only these three elements cannot be called a project management approach. This is because it cannot supply basic proactive functions along with effective procedures and tools to realize our project objectives.

Why quality-driven companies prefer project management

Quality-driven companies seek to improve their quality levels in services and products continuously. In doing so, they have come a long way making use of modern methods for quality control and improvement. You have probably encountered customer organizations where methods such as ISO (International Organization for Standardization), Total Quality Management (TQM), Six Sigma, Kaizen, or the Deming Cycle are used. These days, quality awareness is the rule rather than the exception, as quality has become a competitive instrument over the years. One of the best examples illustrating this is Toyota. They became the largest car manufacturer in the world, owing a great part of this success to their quality management strategy and the branding of it. Many others followed, either inspired by the example of successful quality companies such as Toyota, or even because they were forced to do so. Today, many suppliers don't have a choice, but need to conform to standards such as ISO. As IT professionals, we do not have to look far to see quality management arising in our daily jobs as well. Information Technology Infrastructure Library (ITIL), a widely-adopted and consistent documentation of best practice for IT service management (ITSM) and Capability Maturity Model Integration (CMMI), a process-improvement approach that helps organizations improve their performance, are the models that describe how IT departments function today.

Over the years, the focus of quality control and assurance processes has also shifted. Quality managers want to prevent defects rather than just detect them. They want to manage proactively by continuously learning from previous experiences. So when you plan to implement a software solution in this type of a company, it should not come as a surprise if they are looking for a quality approach demonstrating proactive ability. To do so, you not only need to have a good implementation methodology in place, but you also need to be able to capture, demonstrate, and realize the real value of this methodology. A few slides on phases, meetings, and a planning sheet will no longer be sufficient. Let's not mince words—quality management is on the rise and this will have a significant impact on how customers will expect you to manage your projects. You can no longer sell quality by means of individual efforts and heroics. Instead, you need to demonstrate a repeatable, integrated, and standardized approach.

The four pillars of project success

In the previous section, we discussed the reasons why we need project management and how we can overcome the resistance to it. In this section, the most important elements constituting the intrinsic value of a project methodology will be discussed.

People can quite easily get lost in details when evaluating different methodologies to support their project delivery strategy. Overwhelmed by many procedures, steps, activities, and documents, they grope around in the dark for the true intrinsic value. This section will provide you with four valuable indicators in your search for a supporting implementation methodology.

Communication matters

We all know how important communication is in terms of our project's success. When we think about some of our less successful or even failed projects (a minority of course), we frequently blame them on bad communication. We usually do not walk around blaming the project's failure on an incorrect formula in our spreadsheet or on a system error in our planning software product, but bad communication is always a valid reason. Now, what do we mean by this? Does this mean we did not speak enough? Did we have enough meetings, or should we have called our customers much more? What actually is good communication?

Communication is everything and is present in everything we do. It is estimated that three-quarters of our day is spent communicating in some way. By means of communication, we steer and manage the things we do. The lion's share is taken up by speaking and listening, while only a small segment of that time goes into reading and writing.

Agreed, reading and writing project documents is important, but that doesn't mean we are really communicating as this involves speaking and listening as well. Being a good listener is an essential element of good communication. Epictetus, a Greek Stoic philosopher once said that: nature has given us one tongue but two ears, so that we may hear twice as much as we speak.

Most of us have experienced this already in our daily project work. We manage our projects by communicating. Phone calls, e-mails, meetings, live meetings, and chats are all vital elements of our project management tool set. Nobody usually speaks about it, but there is a good deal of complaining about those project documents that nobody ever appears to read. Sometimes, it feels like putting books in a library that nobody ever visits.

What do we need to consider when planning for effective project communication? Of course, we need communication skills, but even the most gifted speaker or active listener will not be able to fulfill the communication needs in a project that does not allow effective communication.

The rules of thumb covered in the following four sections are indispensable for effective communications.

Rule number 1 – communication requires interaction

Communication is a two-way activity between two or more people. It is usually triggered by an interaction or an event. To make good communication possible, you need to plan your project interactions accordingly. Without customer interaction, good communication will be hard to achieve. The following diagram illustrates typical planned customer interaction levels in real-life implementations:

We usually have many interactions with our customers or prospects during the sales process. Meetings, follow-up calls, demonstrations, customer interviews, and account management visits are all part of the planned interaction management to close the deal. Because of these interactions, we also have the possibility of having good communication with our customer's stakeholders. Interacting with them means that we must speak with and listen to them, basic conditions for effective communication.

When the real implementation project kicks off with the analysis phase, we typically still have sufficient planned interactions by means of kickoff meetings, workshops, and interview sessions. However, after these activities, interaction levels may drop significantly. We tend to isolate ourselves during design and development phases while working on technical and functional designs and executing development activities. Some people blame this on the involvement of technical consultants in these stages of the project life cycle. This is due to the stereotypical view that people have about technical consultants. These consultants start to become quite active during the design and development activities and are known for not being the best communicators. If this is what you were thinking, you'll need to think again. The problem is not that some people carry out their tasks in a concentrated way for which they need an isolated environment. Rather, it is that no other activities triggering customer interactions are planned. This kind of planning, lacking a sufficiently planned level of customer interactions, endangers your project communication. This creates a "communication black hole" that can be quite large if the durations of your design and development phases are significantly long. Think about the impact: no customer interaction means no communication and no customer involvement.

When we start preparing for Go-Live for the new system, the customer interaction level suddenly starts to rise again. That is because we often have an overplanned deployment phase. Everything we didn't plan for in the design and development phases needs to be done in the deployment phase, resulting in many customer interactions. Now maybe after months of low levels of customer interaction and communication, we suddenly need to communicate and interact ceaselessly. This won't be easy for the consulting and customer teams as they are missing communication routines and culture by now. In this kind of scenario, you also need to communicate a lot in a short amount of time. The receiver of your communication will experience problems in continuing to comprehend everything and may build up some (additional) resistance because of this.

Interactive communication must be equally spread over the complete project life cycle and not concentrated in a few moments. The existence of such communications depends on your planning. The cause of failed project communications is not necessarily found in the lack of communication skills of your people, but it may be the organization of the project life cycle itself.

Rule number 2 – e-mail does not equal project communication

You would think that people use e-mail communication because this allows them to stay within their comfort zone. Delivering bad news, informing about decisions, and asking for accountability is far more easily done from a comfortable chair and desk than in face-to-face conversations. There is no need to change places. You just write down what you want to say (your machine will not criticize your message) and you can send your message exactly as you intend: easily, quickly, and efficiently.

Yes, e-mail communication is without any doubt convenient in all possible ways. This makes it indispensable, and there is nothing wrong with using e-mail for communication. However, because of its convenient character, it has known pitfalls as well. E-mail is addictive, and we tend to use it all of the time—in all circumstances and for all communications. This addiction will not make our project communications any better. Good project communication also requires regular interactions, including active listening and speaking along with non-verbal communication.

Facial expressions, body language, and intonation can provide you with a treasure trove of information about people's emotions, motivation, stress levels, and much more. Studies show that when we communicate, 80 percent of the information we receive comes in the form of non-verbal communication. This is also expressed in a Chinese saying: Beware of the man whose belly does not shake when he laughs. If you use only e-mail as your means of communication, you will not be able to identify such things and will miss the opportunity to respond appropriately. Sir Karl Popper stated that it is impossible to speak in such a way that you cannot be misunderstood. When using e-mail, the chances of getting misunderstood are definitely higher. As a project manager, you need to motivate stakeholders and team members, sell your opinions and visions, communicate decisions, and bring both good and bad news, and you need to do this continuously. How effective your communication is in these circumstances will determine your success as a project manager. You need to make sure that you are well understood.

You also need to be aware that people may read your e-mail much later than planned. Your message can end up in a long queue of unread e-mails, even when marked as important or urgent. Thus, even though delivered instantaneously, your communication by e-mail does not really happen in real time.

Yes, e-mail is convenient and can be effective, but not at all times. You need to step out of your comfort zone regularly to face your team members and stakeholders, and you need to do this right from the start until your project is closed.

Rule number 3 – be brief

Documents are an important element of your project communication mix. They support meetings, inform your team members and stakeholders, ground your project decision making, and facilitate validation and closing processes. Project documents are vital input for your communication, but unfortunately, not all documents have the intrinsic quality of fulfilling these goals. As said earlier, there are a good deal of complaints about those project documents that nobody ever appears to read. Those types of documents do not support or facilitate anything. They serve as an alibi for a so-called quality approach, but usually only represent a one-way ticket for the file cabinet. These documents are experienced by most people as a waste of time and are responsible for misperceiving project management as a bureaucratic activity. Then, what kind of intrinsic elements make up good project documents?

One of the most important things is to safeguard the readability of your documents. Doing your project documentation is not a championship in writing the most number of pages. A long document saying nothing is much easier to write than a short document saying it all in a few lines. Most of these long project documents are unstructured, miss good conclusions, and contain too many gray areas. They also tend to get out of balance in terms of content, including having too much content devoted to introductions and less complicated topics, while lacking good content on the more complex and rather important issues. This makes these documents not only hard to read but incomplete as well. Why do we need so much paper to bring insignificant content? Now put yourself in your customer's position for a minute. Is it so surprising that these kinds of documents aren't read thoroughly? Would you like to read a fifty-page document lacking finer points and conclusions?

You should also take into consideration that all software projects generate a significant quantity of project documentation of all kinds. That means that your customer should review a large number of documents throughout the complete project life cycle. They need to go through this on top of their daily jobs. So, do not expect that they will read all of your flowery prose. For all of these good reasons, you need to keep it short.

Coming to the point requires real effort. Most project stakeholders review project documents assiduously for actions and conclusions but usually find unsolicited analyses, backgrounds, and arguments. Now what can we do?

First of all, you need to create awareness about this issue among all of the team members contributing to the project documents. Specifying a recommended maximum number of pages for each type of document will help. Predefine the structure of the documents, including the sections for actions, issues, and conclusions, and make sure that the customer-facing documents do not include too much jargon and long technical descriptions. Communicate in the language that your customers use to communicate. And last but not least, be sure to include graphical elements such as diagrams and process flowcharts. These elements increase the readability significantly and will make your content much more attractive for the reader.

Rule number 4 – set clear expectations

If you want your customer's and team's involvement throughout the project, you need to work on setting clear expectations about who is expected to deliver what, in what manner, and when. If you want to ensure good communication in your projects, you need to advise your stakeholders in the same way about your communication approach. Here is what we need to explain:

· With whom to communicate

· Who will communicate

· What to communicate

· How to communicate

· When to communicate

This is sometimes also referred to as a "communication plan", commonly used by some, but a frightening idea to others. No matter how you feel about a communication plan, do not underestimate the importance of defining and explaining these communication elements. Without these beacons, the project team's communication will be uncontrolled and unguided. At the same time, your communication strategy needs to align with your overall project life cycle organization. For example, when can your customer expect the delivery of a document containing the requirements or design of a proposed solution? Do you organize a meeting to discuss this document? If so, who should attend? Do you need a validation of this document and who is authorized to sign off? Do all documents need to be signed off or just a few? How much time does the customer have before signing off? What are the consequences when they don't sign off? What is the relation with the phase-based approach? Your customer needs quite a lot of information before they can play your game.

Once your customer knows what to expect and how to communicate, you need to practice what you preach.

A proactive attitude makes the difference

Project success is highly dependent on your proactive abilities. Sometimes, project managers behave more like spreadsheet gurus than managers. They use and maintain complex spreadsheets in which all of their project data is centralized. These spreadsheets include complex formulas, generating all kinds of trends and results for the project. There is nothing wrong with these spreadsheets, but by themselves, these tools do not manage anything. These tools need to provide the project manager with indications and early warning signals that some things need steering or correcting. They need to trigger proactive and corrective project management action. This is what project management is all about—being proactive and correctively steering the project. As a project manager, you need to manage your team, which requires a practical approach guided by the insights that tools such as spreadsheets deliver. What can help us deploy proactive project management? We'll take a look in the following subsections.

Rule number 1 – look ahead and prevent

A proactive attitude requires looking ahead instead of backwards. As a proactive project manager, you need to focus on prevention rather than detection. You need to make sure that your project reporting and tools will not explain your past failure in detail but will help you prevent and resolve any issues and problems on the horizon. The first thing that you need to do is switch your mindset from the past to the future, from problem identification to problem prevention, and from reactive to proactive.

Rule number 2 – be proactive with interactions

Proactively keep up continuous interactions with the customer and the consulting teams. In projects, we face issues, risks, changes, quality, scope, and much more that can impact our time and cost performance. So, if we want to provide reassurances about time and budget, among other things, we need to manage these daily risks and issues proactively. To start with, this approach requires that we know our issues and risks. We can identify them only by interacting with the customer. Interactions such as testing, validating solutions and concepts, meetings, and evaluation moments usually reveal our project's issues and risks. It is very unlikely that you will discover issues and risks at times where the interaction level is low. Secondly, we need to make sure that we identify our challenges as early as possible.

Being proactive means always being one step ahead. This means when you have planned most of your customer interactions for the end-of-the-project life cycle, your ability to achieve proactive management will drop significantly. Similarly, you will lose your ability for proactive management when you and your team postpone all customer interactions to the end of the project life cycle. So, concentrating on customer interactions in the beginning and at the end of the project cycle will not give you the necessary opportunities to be proactive. How you plan and execute your project life cycle is the key to being a proactive project manager.

Rule number 3 – a measure for early warning signals

If you want to know what is on the horizon, you need to identify early warning signals of what may come. These signals do not always come to our attention by themselves. They can remain unnoticed if we do not plan for them. If you want to be proactive in your projects, you need to think really hard about what you want to measure. A proactive manager reads the impact of the current progress on future activities in their projects. You want to know if your current performance will cause cost and time overruns and you need to know why. So, if you are using an advanced spreadsheet to measure your performance, you need to ask yourself if it tells you something about the future of your project or only informs you about the past performance of this project. Your measurement can only reveal early warning signals when you are not reporting hot air. Your measurement needs to be based on the integration of scope, schedule, and cost. So, if you do not have a definition of your scope, schedule, and associated costs, you cannot expect to measure early warning signals.

Before you even start measuring, you need to have at least the following project essentials:

· The scope of work broken down into smaller units

· A time frame planning for each of these units of work

· Resources and approved costs to meet these units of work

Only then can you start thinking of how to measure performance. Early warning identification must be done right from the start of your project and should be carried out regularly. Starting to measure the performance when more than half of the project has been done cannot be considered proactive.

Some project managers settle for two-dimensional project reporting. They dive into the project data and their reports look something like this:

· Budget: 1 million (euro, dollar, and so on)

· Project duration: 12 months

· Time spent: Six months

· Cost spent: 0.4 million (euro, dollar, and so on)

After these six months, the project manager reports to the company executives and customers that they are right on track in terms of budget. They probably also report that the team is performing well, the quality is okay, and no major problems are on the horizon. What an excellent progress report! Or is it?

What this project manager forgot to do is integrate cost and time with the scope to be delivered. Let's assume that in these six months, six units were planned to be delivered. Crucial questions here are how many units have been delivered and accepted in six months with the 0.4-million budget? This project is suffering a huge time and cost overrun if only three units have been delivered and accepted. You need to make sure that you are not misinforming yourself and your stakeholders with measurements that do not measure appropriately. If you want to be proactive, you need to have a measurement system in place that is capable of detecting early warning signals.

Creating a guiding project culture

There is a flood of complaints about customer involvement when speaking about less successful implementations. Some project managers also express that projects tend to take on a life of their own. In these scenarios, the project is narrowed down to the planning and execution of tasks by individuals. Both the customer and consulting teams appear to be disconnected from any attitudes, values, beliefs, priorities, and behavior that should be associated with this project. Driving the energy and commitment of your team to take a project from the initial idea through deployment will be a hard nut to crack with this kind of disconnection. Creating a guiding project culture merits particular attention from you as a project manager.

You need to make sure that all stakeholders and team members are aligned with the following:

· The project objectives

· The benefits of this specific project

· The manner of working

· The manner of communication

· What defines quality and how to achieve it

· Everybody's role and responsibilities in this project

· The changes that accompany the implementation of this project

· The risks associated with this specific project

· The scope that will be delivered

· Those parts that are considered out of scope

It's probably stale news but you may fall into a trap when taking this for granted. Do not assume that everybody involved in this project is aligned. Aligning people and having them committed to the goals, benefits, and approach will consume a lot of your energy, but it is absolutely crucial to your success.

Culture is a set of stated and unstated, and explicit and implicit, beliefs and assumptions that are shared by a group that shapes and harmonizes the behavior of all its members.

You cannot assume that customers are committed to your plan if they are not enthusiastic about the goals and are unaware about your approach. How can they support your approach if they are ignorant about the reasons for and benefits of this approach? They need to know what is expected from them and how much commitment they need to plan for.

The same goes for your own internal team members. They need to be equally aligned in order to fulfill expectations. Having a good adopted and intrinsic, strong implementation methodology is, without any doubt, a move in the right direction. This will allow your team members to have a strong understanding of how your company is doing implementations and why you are doing them in that way. Having this in place will save you valuable time aligning the consulting team members with your approach as they already share these values and beliefs. What remains is a solid debrief of the specific customer case and upcoming project. If you are dreaming of more self-steering teams, you need to make sure that they share your company's values and approach.

So, you need to make sure that before you jump into the execution tasks for your project, all of the stakeholders and team members are aligned in terms of the beliefs and vision of your approach and about all crucial elements of the specific project. You need to evaluate if this alignment is strong enough to act as a solid undercarriage for your project vehicle. The road will become bumpy, and a solid undercarriage will be a necessity, not a luxury.

The importance of closing

Closing the project proves to be a real challenge for many. At first glance, it looks easy and straightforward. After the Go-Live and some additional support, you ask the customer to sign off for the delivery of the project, and once signed, your project is closed. Unfortunately, most of us have experienced that closing usually doesn't go off that smoothly. In fact, many projects remain unclosed forever.

The first noticeable finding is that project team members do not have the practice of closing. Analysts focus on the delivery of good business process descriptions and the capturing of requirements, developers want to show their superior technical solutions, and project managers strive for on-time and on-target Key Performance Indicators (KPIs). As a group, their key target is to deploy a new solution, followed by a successful Go-Live. This is basically what they have on their radar. But who is responsible for working towards closing? Closing is not as self-evident for project managers as it is for sales people. Closing is a key element in the sales cycle, and being able to close a deal is the key strength of a sales manager. They are aware of this crucial process and improve themselves continuously in their closing skills. If we want to be more successful at closing our projects, we need to start realizing a closing culture within our project teams. Why we need to close, how can we facilitate the closing process, and who is responsible for closing are some crucial questions we need to find the answers to.

Having defined a project as a temporary endeavor implies closing a project. Not closing a project will transition it from a project to an operation. Unfortunately, we do not have a budget for that operation, and we probably do not have a defined way of managing operations at customer websites either. This can become a true burden. If not closed, customers will continue to ask for all kinds of changes, enhancements, and various services for which funding will be under discussion. You will end up having a lot of meetings trying to find compromises to determine what is still within the scope of the project and what is not, and you will need to do this for as long as the project isn't closed. Maybe your project was profitable until Go-Live, but at this point, your profit is starting to get squeezed dry. There are also important psychological elements attached to closing. Successful closing reinforces the feeling of success. People need successes in their professional careers to stay motivated, and success gives them the incentive to carry on striving for ultimate success in their future projects. The customer team members will share the sensation of having realized something important for their company, and they will share the benefits with the entire organization. And after all of the hard work and effort, they are entitled to this moment of glory. When we do not close our project, other psychological effects will unfold. With no clear end to the tunnel, people will tend to think negatively about the project and will feel discouraged.

The customer team members will not evangelize the benefits of their new solution. Instead, they will become irritated by even the smallest unavoidable issues. The chances that your consultants and developers will remain motivated for upcoming projects are minimal, especially when they already have a track record of unclosed projects. For these and many more reasons, you need to continuously work on improving your project's closing capabilities, just like sales people do.

Now what makes closing so difficult? Let's focus on two important elements, namely:

· The existence of a "closing culture"

· The elements of the closing exercise

The customer organization needs to be familiar with closing and signing off. After deploying the project, if you ask your customer to sign off for the closure, and this is the first moment they really need to sign off, your chances of realizing this are minimal. Signing off can make customers a bit suspicious and insecure, especially when they are unaware of the process. By applying sign-off procedures from the start of the project, those barriers will become much smaller as your customer is already familiar with closing routines.

The closing exercise itself will bring it all together. You will need to prove that your team delivered what was promised, that the quality is up to the standard, and that the organization can use it with the defined benefits in their daily routines. This burden of proof requires good preparation, a strong dossier, and a good relationship with your customer. You will have the best chance for success when your dossier has already been created through a long validation cycle. Things such as approved documents describing the scope, validated change requests, confirmed test results, and signed-off milestone review documents will make your case strong. At this point, you can evaluate how strong your approach was and how good your communication was throughout the project life cycle. Can you think of a good way in which to close the project without these essential elements?

Project management essentials

Developing and implementing smart project management practice requires profound knowledge of the discipline. The project management discipline cannot be digested in one small bite as it encompasses the knowledge of various domains and disciplines. It deals with complex specialties, such as scope management, cost and time management, quality management, human resources management, communications management, and integration and risk management, and it can overlap with other management disciplines. This chapter does not aspire to examine all of these domains, but will take you on a journey to discover some of the most essential elements of managing projects.

A project life cycle and its phases

When talking about project management and implementation methodologies, people spontaneously start talking about their phase-based approach. If you review the content pages of implementation partner websites, you usually see diagrams illustrating a project life cycle broken down into different phases, and when you attend commercial meetings between partners and their prospects, the explanation of the implementation approach is usually also done in terms of phases, as follows:

This phase-based approach of a partner is inspired by the Microsoft Solutions Framework (MSF). A project run is executed and managed by five different phases. Each phase is closed by clearly defined milestone deliveries, such as approval of scope and project plans, completion of scope execution, approval of release readiness, and completion of deployment.

The following diagram shows these phases:

The following diagram shows an even more exotic variant of the phase-based approach, providing eight phases to manage the project:

Therefore, in most partner implementation methodologies, phases are important; but do we really understand what phases are and do we respect the phase-based practice in our daily projects? Let's try and find answers.

What is a phase?

Phases represent a breakdown of the project life cycle into smaller time units. Moving from one phase to the next in a sequential manner is typical for the waterfall model. The ambition of the waterfall model is to define the requirements and designs quite early in the project life cycle by means of separate phases. You can transition from one phase to another only when all of the work planned for that phase has been done, and when all of the necessary deliverables are produced and accepted. The following diagram shows the typical waterfall approach:

The essence of the phases is that they increase the ability of management control based on the idea that you cannot eat a whale in one bite but that it must be digested in small pieces. The following diagrams show two examples of a project approach:

Project A is organized into four planned phases. The activities are grouped and planned to be executed in their corresponding phase. The progress of execution will be monitored and controlled for each phase. The phases will be closed when all of the milestone deliverables are produced.

Project B is organized into one phase. All of the activities are planned for execution in this phase. The phase will be closed when all of the deliverables have been produced or along with project closeout.

Let's assume that Projects A and B have exactly the same objectives, stakeholders, risks, time frame, budget, and scope. What is the difference between Projects A and B? The teams will need to execute exactly the same activities in both projects, generating the same deliverables in the same time frame and budget. The only difference is that Project A is organized into four phases, while Project B is executed in one and only one phase. In Project A, the teams can start working on technical and functional designs only when the planned interviews, workshops, and documentation activities are finished, and all of the deliverables are generated. This will be controlled and validated by both consulting and customer project managers. In Project B, the teams may have already started development before the technical designs are ready, and there are no real formal evaluation moments planned in between the activities and deliverables. So, the nature of the work is not changed, but by using phases, you control and validate the progress at defined moments. The purpose of this approach is to organize and control your timeline, leading to more management control. Thus, the ability of the project manager to really manage the progress is increased significantly in project A and the chances of success are therefore much higher in Project A than they are in Project B.

The following diagram shows a typical scenario that is most likely to occur because of no controlled transition of the phases in Project B:

This typical scenario may unfold when not working with phases. The risk here is that the activities and deliverables may systematically be postponed. This causes a high concentration of to-dos at the end of the project life cycle and will bring on difficulties in planning and realizing a good deployment. In this scenario, it is also common that no major problems are reported until the deployment phase, which is not so surprising when most critical activities have been postponed to the end of the project life cycle.

By the end of the project, the project manager will diagnose an increasing number of issues. Knowing that one train may hide another, it will not take long before the project manager realizes that the project is now entering a risky phase. A typical question is: "why didn't we know about this earlier?" You can find the answer by just looking at the planning of such a project life cycle—you are trying to eat the whale in one bite and this bite was badly planned.

Respecting the phase-based approach

If your implementation methodology includes a phase-based approach, and you really support this approach, make sure you also implement real phase-based practices. Just having named phases on your presentation slides will not really contribute to your real-life projects. Not respecting the phase-based approach reveals itself by the following characteristics:

· Not formally closing the phases

· Initiating new phases without finishing the planned deliverables from the previous phase

· Underplanned and overplanned phases

If you do not close your phases formally and move to the upcoming phases without finalizing the work from the previous phases, you are not respecting the elementary functioning of the phases. This implies losing the benefits of this approach as well. It will not only cost you the ability to track your progress phase by phase, but you will also miss a great opportunity to work on your communication and closing culture with the customer. Implementing phases provides the great benefit of bringing in a closing culture on a step-by-step basis. If you close each phase with a standard procedure together with the customer, they will become quite familiar with closing throughout the project life cycle. Building communication around these formal moments can only be to your advantage.

The following diagram illustrates a project life cycle in which some phases are underplanned and the others are overplanned:

The preceding diagram clearly shows an imbalance in the planning of activities spread over the phases. You can conclude from this diagram that the project is managed in two phases instead of four, with an overplanned Deployment phase.

So, if you really want to work with a phase-based approach, you need to make sure that you respect the functioning of such an approach and you plan your phases in a balanced way. If you disregard these basic rules, you must conclude that your implementation practice is not managed by phases.

Project management processes

Project management processes represent a logical grouping of activities performed to produce a specified set of deliverables. Each time that you need to produce deliverables, you need to obtain validation for the goals, plan how you are going to execute, produce while simultaneously controlling this execution, and once ready, close the assignment.

In the following diagram, you will find the project management processes as defined by PMBOK:

Initiating processes help you define and obtain authorization for the new project or phase. Planning processes help you establish the scope of the project, refine the objectives, and define the approach required to realize the objectives and deliverables of either the project or the phase. Executing processes represent the activities performed to complete the planned deliverables. This will involve coordinating people and other resources to execute the plan. The processes required to track and review progress and status regularly, and to identify deviation from the plan, are gathered under controlling processes. Once finished, each assignment, phase, or project should be formally closed by the processes facilitating this closure. These processes are called closing processes.

These processes are not the same as your phase breakdown of the project timeline. In fact, the project management processes occur (or should occur) in each of your phases. Depending on the phase, the dominant processes will be in place. During the project preparation phases, such as during the diagnostic and analysis phase, initiating and planning processes can be more dominant, but this does not mean that those will be the only processes during that phase. You also need the execution, controlling, and closing processes in your analysis phase.

It is important to notice that you always need to give attention to the closing processes. The closing process needs to happen in every phase or iteration. Closing is not something that you exclusively need to reserve for the end of your project life cycle.

The preceding diagram conveys that your planning outcome will direct the execution and controlling processes as two-way traffic. How you execute these processes will affect your planning, and controlling can reveal the necessity of the planning changes. Once you start executing the work necessary for producing the planned deliverables of that phase, you need to start monitoring and controlling this process. However, this needs to have an impact on your execution by means of corrective actions. If your monitoring has no impact on the execution, you may plough the sands.

Breaking it up!

If there is one thing you need to do to make your projects manageable, it will be breaking them down. You should be aware of the breakdown of your project life cycle into smaller time units, such as phases, but breaking down your scope is equally important. The best project plans are based on a good breakdown. You can find excellent project plans when buying toys for your kids (or for yourself). A good example is the Emergency-Doctor's Car from Lego. This includes a textbook or ideal project plan.

The following diagram shows the best project plan in the world:

The preceding diagram from the building instruction plan provides you with a clear definition of the scope. You will immediately know what to build and what not to build. The next diagram illustrates that Lego masters the skill of making rock-solid project plans. The building instruction plan is built up out of steps and subdeliverables. This building project will be executed in thirteen steps, with each step producing clearly defined subdeliverables.

For example, in step 5 you need to produce the subdeliverable shown in the preceding diagram. You can start doing this only when you have finished step 4, and when the subdeliverables 1, 2, and 3 have been assembled.

Each step has the same approach. To complete step 6, you need to have finished step 5 and produced additional subdeliverables in step 6. The Lego building instruction plans are excellent project plans based on the waterfall method and the project management technique of the breakdown and creation of subdeliverables. Were you aware that your kids have already mastered these techniques?

Most project management methodologies promote the use of a Work Breakdown Structure (WBS). WBS is the fundamental project management technique, defining and organizing the total scope of a project by using a hierarchical tree structure.

In 1976, the book Managing High-Technology Programs and Projects third edition, by Russell D. Archibald, John Wiley & Sons, Inc., defined a WBS as a graphical portrayal of the project, exploring it in a level-by-level fashion, down to the degree of detail needed for effective planning and control. It must include all of the deliverable end items and the major functional tasks that must be performed.

The first two levels of a WBS define a set of planned outcomes that represents 100 percent of the project scope. A well-designed WBS describes planned deliverables instead of planned activities. These important deliverables are much more controllable than activities. We need to concentrate on what has been produced and not only on the effort; activity is not an achievement. Deliverables or work not included in the WBS are not in the scope of the project.

The following diagram illustrates a possible WBS structure for a Dynamics ERP project:

Your WBS may look like the preceding diagram, but may be structured in a completely different way. The WBS Standardization Committee from PMI communicated the following:

"Project managers may find themselves in many different situations and it would be inappropriate for PMI to place restrictions on their options. The WBS is a project management tool that can be used in different ways, depending upon the needs of the project manager. Therefore, there should not be arbitrary limits set on how the WBS should be created."

A WBS represents the way that the project manager plans to manage the project. This includes planning, estimation, and controlling, all based on the WBS. In this way, a WBS is your ultimate instrument for the integration of scope, cost, and time. It is also an excellent instrument to implement a "universal project language" within your project, making the project communication more comfortable.

From estimate to follow up

We do not need to explain how important good estimates are in terms of the success of any project. Both time and cost estimates define your comfort zone within the upcoming project, and most of us, at some time or the other, must have suffered from underestimated projects. Studies have identified that most of the cost overruns are caused by poor estimation skills. Furthermore, people generally tend to underestimate when asked for cost or time estimates for new, upcoming projects, and we usually need to come up with estimates at times when detailed information on the project is not yet available. Nevertheless, stakeholders prefer accurate cost and time estimates in a context in which uncertainty is the only certainty. Higher accuracy demands greater effort and thus adds time and costs. And to make it complete, project estimation processes can't be bought off the shelf. There is no common industry benchmark for estimating a package implementation size. Getting close to despair? Wait, there are a lot of good estimation techniques documented and you can find plenty of literature on these matters.

WBS as an estimation instrument

One of the elements that we want to bring to your attention is one of the reasons why most of us tend to underestimate projects. Availability is a cognitive heuristic in which a decision maker relies upon the knowledge that is readily available rather than examining other alternatives or procedures. In other words, people have difficulties imagining all of the ways events can unfold, and out of sight equals out of mind. Therefore, we tend to assume that everything will go as we expect and this makes us overconfident in our estimation at the beginning of the project life cycle.

Now what can we do? There are quite a few things we can try, such as producing alternative scripts for how the project may unfold, drawing hierarchical diagrams of all that can go wrong, making explicit assumptions, and asking others to challenge us. WBS is an excellent tool in your estimation tool set, and it will prevent you from assuming and forgetting too many things while estimating. The creation of a WBS will make you think of many possible events in your project. Even better is the use of WBS templates. These are WBSs developed on the basis of previous projects. If you combine this with the use of project types for which you have an associated template WBS, your estimation accuracy will most certainly increase.

Another element that we want to bring to your attention is the subject of your estimation. We usually estimate the solution size or package complexity, including things such as the configuration effort to suit the requirements of the business processes, and the effort to produce custom objects to address the gaps in the application. In this context, we also evaluate the implementation and business complexity, but we sometimes forget to take the organizational complexity into consideration. Recent studies have identified that the implementation effort not only grows with the number of modules and submodules that are selected for the implementation, but that each user also adds an organization component of costs. We need to make sure that we include all of the complexity in our estimation scope. This may also be really relevant when we implement our solution in different departments of our customer's organization. The different departments will have different users, and they can have varying experience and skills in terms of software solutions and procedures. The following diagram illustrates how you can organize your WBS in such a way that it will facilitate the estimation of the different complexities in the different departments:

Follow up based on WBS

You can only follow up what you have planned and estimated for. Project reporting is in some cases disconnected from what was planned and estimated. The breakdown used for the estimation and initial offer can be quite different from the activities planned and controlled later on. It looks as if the estimation, planning, and monitoring live their own lives. You cannot expect great results in terms of manageability, and cost and time overruns have a high probability in those cases. The WBS is used for defining work packages as well as developing and tracking the cost and schedule for the project. Once you have your deliverables and work packages defined and planned, you can easily follow them up using different possible monitoring techniques.

A technique that you can consider using is the "Earned Value" concept. In their book, Earned Value Project Management second edition by Quentin W. Fleming and Joel M. Koffleman, Project Management Institute, Inc., they describe the focus of Earned Value as the accurate measurement of physical performance against a detailed plan to allow for the accurate prediction of the final costs and the schedule results for a given project. They also state that the WBS is an integral part of the Earned Value concept. The reason for this is that the Earned Value concept requires the integration of the technical scope of work with the time commitments and the authorized resources.

WBS as a central concept

The following diagram illustrates the benefits of WBS in your projects:

The WBS is your starting point and control point in making estimates and planning, derived from the activity lists. It is the necessary integration instrument for making the monitoring and reporting of activities possible, and it acts as a global communication instrument throughout the complete project. These are significant benefits from an easy-to-use instrument and are therefore worthwhile to use in your own implementation practice.

Adopting project management

As you may have heard, there is no such thing as a free lunch. Adapting to a new approach, including a new vision and new procedures, steps, documents, and tools, requires continuous effort and management. This section will inform you about the change in aspect of project management adoption and will inform you about the reasons why change initiatives fail.

The tireless quest for the perfect espresso

We may have something to learn from coffee beans. When we say coffee, you may think about Illy. Founded in 1933 by Francesco Illy, Illycaffè produces and sells a unique blend of high-quality coffee. Ernesto Illy revolutionized coffee growing in Brazil and elsewhere in the world. In his tireless quest for the perfect espresso, he encouraged the production of top-quality coffee and constant investment in research. Mr. Illy said the following to The New York Times in 2001:

"Our goal is perfect beans, zero defects, and we think we get close to that."

He also said this:

"It takes 50 beans to make a one-ounce cup of espresso. One bad one, and I guarantee that you'll taste it. It's like one rotten egg in an omelet."

Microsoft partners don't make coffee; they work on various projects, which is their business. If you have one big bad project, you'll definitely taste it as well. Profit goes down, your customer satisfaction deteriorates, and even more importantly, your employee satisfaction will not become any better. Those few failing projects are the rotten egg in your company omelette.

So, this should be your goal: perfect projects, zero defects, and trying to get as close to that as you can. This is probably obvious, but then again, it's not so easy. You need to make sure that all your projects are successful at all times. This is a continuous effort and involves everyone in your team. Everybody (sales, project management, consultants, and developers, among others) needs to be aligned, knowledgeable, goal driven, and proactive. Your people and processes are the beans in your cup of espresso.

Embracing change

Adapting to a project management methodology doesn't come easy. Mark Twain said:

"I'm all for progress, it's change I don't like."

It requires the continuous and true efforts of a large team. Besides the continuous effort, there is also the element of change, and as we know, change isn't easy. It requires people to alter their current ways of working and adapt to new procedures and tools. You will need to prepare for stiff resistance by starting with the essentials, such as the executive buy in. Without executive and management support, your change program will be doomed to fail. Therefore, the executive team must confirm a need and a compelling reason to adapt to a new or enhanced approach. They need to have a strong desire to resolve known business pain points, and they must share and communicate the importance of adapting to the new procedures with the entire organization. The book titled Our Iceberg Is Melting first edition, by John Kotter, St. Martin's Press, describes ten reasons why change initiatives do not succeed. They are as follows:

· Underestimating the need for a clear vision of the desired change

· Failing to build a substantial coalition

· Failing to clearly communicate the vision

· Not generating a sense of urgency tied to improved performance

· Not building a plan for short-term wins

· Failing to lead and coach the changes in business behavior

· Failure of the managers to operate in and above day-to-day execution

· Not practicing what you preach

· Permitting roadblocks against the vision

· Failing to anchor the changes in business culture

This should not hold you back from starting your change initiative because the rewards are great, and your business, customers, and employees will all benefit from the quality-improving initiatives. But you should be aware that implementing change successfully requires great efforts.

Indispensable organizational benefits

In the previous section, we discovered that we will encounter many traps on our journey to adopt a rock-solid project management approach. The change process involved will require the continuous and significant effort of a complete organization. Let's concentrate now on reaping the fruits. What benefits are in it for us? Why do we plan for all this effort?

A core competency for your company

By successfully adapting to an intrinsic, strong implementation methodology, it becomes a core competency for your company. This implies that your company excels in understanding the needs of your customers, managing projects on time and within budget, and designing and developing solutions that exceed customer expectations. This will allow your company to position itself uniquely within the market while providing unique benefits to your customers in a way that will be difficult for your competitors to imitate.

Profitable projects

Projects are unique and temporary endeavors, facing continuous risks and lots of uncertainties. Effective and well thought-out project management is a necessity for realizing and maintaining project profits—an economical necessity for the companies making their earnings through the delivery of project services. According to independent study companies such as Gartner, the companies that have developed their implementation methodology to a level of making it a core competency, are rewarded with the following benefits:

· Top performing partners execute deals at a faster pace with new customers

· Top performing partners maintain the perception of high quality in the services they deliver, and at the same time, make more money

· Top performing partners strive for repeatable service delivery, enjoying lower project backlogs with favorable utilization rates

Satisfied customers and happy employees

In services companies, employees are a crucial asset. That's why Human Resources departments invest time in recruiting the right employees, with regards to their knowledge and their commitment to the company. Happy employees are usually more motivated, and the extent to which they align their motivation with the company's goals is linked to your customers' satisfaction. Every employee needs to experience success in the daily job. Queuing unclosed and unsuccessful projects is a burden gnawing employee motivation. It goes without saying that customer satisfaction is also directly connected to your project's success. Solid and effective project management practices will significantly increase your project success, which is proven and illustrated by many independent consulting surveys and reports. Your customers and employees will be much happier when your company develops an implementation methodology to such a level that it is a core competency.

Summary

In this chapter, we went through the emerging and changing aspects of the field of project management. We discovered that some basic and essential project management techniques can easily make a great difference in our approach to project management. Smartly planned project life cycles and phases, along with respecting the phase-based approach and simple techniques such as WBS will bring instant value to your project services chain. We also learned that by safeguarding the four pillars of project success, a solid undercarriage for your project vehicle is guaranteed, which is a perfect insurance for bumpy roads. Do not be misled by the skeptics' criticisms of project management. We learned that their case is not strong enough to bring down the need for project management. However, we must consider and treat the implementation of a new methodology as an organizational change management initiative.

In the next chapter, we will learn about and experience how Microsoft Dynamics Sure Step will empower you to sell new implementation projects, and how it will efficiently prepare you for the upcoming project.