<![CDATA[PMLink - Blog1]]>Wed, 06 Jan 2016 23:50:13 -0800EditMySite<![CDATA[How to Manage an Information Technology Project - Part 1 (out of 3)]]>Thu, 19 Sep 2013 14:01:42 GMThttp://www.pmlink.com/blog1/how-to-manage-an-information-technology-project-part-1-out-of-3Picture
Information Technology (IT) projects are usually run by project managers who use processes such as scope, schedule, budget and quality management to get the job done. These skills are indeed prerequisite to success in completing a project, but other things are needed to deliver complex information technology projects in today’s fast-moving pressure cooker environment.

What do IT project managers need to do in order to be successful? This article examines key challenges to successful delivery of information technology projects, and gives tips, strategies and risk mitigations that can be used to structure and manage a project successfully.

A project is set in motion to achieve a result such as a business objective. A custom web application may be written to improve the productivity of a company’s workers. Enterprise resource planning software may be rolled out to consolidate a company’s data and streamline workflow and processes. Servers may be consolidated to achieve cost savings.

Fundamentally, a project changes an aspect of the organization of a business. A number of people have a stake in how such changes are implemented: managers may look for better productivity or higher sales; users of the software would like ease-of-use and time savings; internal auditors could be interested in security, adequate reporting and adherence to accounting and other standards.

Projects fail when the stakeholders aren’t aware of the details of what the outcome will be, or don’t agree on measurements of success after implementation. As a project manager, some of the keys to success include being clear on who the stakeholders are and working with them to agree at a detailed level on what the outcome of the project will be and how success will be measured. This can be done in a variety of ways. First, scope baselines must be documented, and agreed to by the stakeholders. These baselines include detailed requirements, visuals of how screens and reports will look, and descriptions of business rules, data, and process flows. The baselines include the details of interfaces to other systems, report design, data conversion mapping, application security, and application logging and audit requirements. They also include descriptions of software and infrastructure architecture and the decisions related to how these will be designed. Non-functional requirements such as system performance, scalability and maintainability may constitute a baseline.

Once requirements are in place, estimates must be made for performing the work required to realize the objectives. There are different estimating methods including ballpark or order of magnitude estimating; top-down estimating based on rules of thumb, metrics, or past project experience; and bottom-up estimating, by identifying and estimating each task to be performed. Researching this subject will yield additional tips and techniques. Estimate granularity will vary depending on project size and the needs of the organization, but should be linked to how the outcome will be measured. Estimates are not simply numbers of months, weeks, days or hours, but are also assumptions upon which such numbers are based. For example, the length of project phases and the entire schedule is one of the assumptions.

One reason projects do not meet their schedule objective is because the project milestones are set too aggressively. If the business dictates the dates by which a project must be completed, the project manager can do some work to identify the probability of success, and negotiate scope changes if the probability is low that the project can be completed in the requested time frame. How can the likelihood of success be calculated? A tested rule of thumb is that an IT project is unlikely to be successfully delivered if the schedule in months is less than the square root of estimated person-months of effort. For example, if the estimated effort is sixty-four person-months, a schedule of less than eight months is unlikely to be achievable. If the date is unmovable, it is better to reduce the scope and related effort needed, rather than attempting to bring too many personnel to the project and perform too many simultaneous or overlapping tasks.

When beginning a project, the project manager must understand the budget and work to assign personnel to the project, such that their costs and estimated effort line up with the budget for labor. If there are other costs such as software, network or hardware, making sure at the outset that these things can be procured for the allocated costs, and who will supply them and when, is key to successful delivery. If planned costs are not mapped to expected costs at the beginning of the project, a budget overrun will be a strong probability.

To be continued next week.

Brought to you by PMLink.com. Author: Miguel Ylareina.

Don't miss parts 2 and 3 of this great post!

Join our FREE Newsletter now and we'll let you know everytime we have a new article posted on our Blog!
Also, by joining our Newsletter you will receive this e-book free of cost. 

Join Now!
<![CDATA[Managing multiple projects? A strategy for handling conflicting priorities]]>Wed, 11 Sep 2013 11:11:31 GMThttp://www.pmlink.com/blog1/managing-multiple-projects-a-strategy-for-handling-conflicting-prioritiesPicture
Something that is rarely talked about with project management but is all too common is the need for project managers to look after multiple concurrent projects. When an organization has invested in the skills of a project manager and they prove their worth, this often results in the paradox of that individual being given more than one project to handle and thereby making it more difficult for them to achieve future success. However, all is not lost. It is possible to manage multiple projects at the same time without dropping the ball. Here is a strategy to get you through it.

Divide your day

One of the best ways in which you can comfortably juggle multiple projects is to review your time management approach and how your work gets completed on a day by day and week by week basis.

First, spend a week logging all your time spent against every project, and what task you were doing. You may even want to consider using a time management tool for this; there are some perfect good and free ones online. Once you have the time logged, you can begin analyzing where it is spent. Are you jumping between tasks on a regular basis? Are you starting and stopping tasks rather than getting one thing completed? That is a sign that you are not using your time efficiently.

After analyzing, reorganize your working day into components, and try and stick to that arrangement. The components may not necessarily be project-specific but you might find a task-specific approach works better for you (for example, reading and responding to all emails once a day). The purpose of this exercise is to really try and make sure your time is well organized, that each of your projects gets a fair balance of your attention, and you are not getting side tracked by fire-fighting one at the expense of the others.

Delegate appropriately

Review the tasks you are carrying out on a regular basis on your projects and ask yourself the following question: are you doing any tasks that could be delegated to someone else in your team? It is common for project managers to take on tasks to try and speed up the project but you risk doing this at the expense of managing and overseeing the progress of the project itself. Your team is there to get things done, so don’t be afraid to assign things out when it is appropriate to do so. You may even find that your team appreciates the fact that you are giving them more responsibility. Make sure to set deadlines and ask for progress updates from your team, so that you are not spending extra time trying to find out when things will be complete by.

Talk to customers about priorities

Taking to customers about their priorities is often seen as a bad move, because it automatically suggests to the customer that you cannot keep your commitments. However, it doesn’t have to be this way. Talking about priorities is really about keeping the communication lines open with a customer. What you really want to find out is what their motives are for the project, what the most important aspects of the project are, and what elements of the project are more flexible than others.

This gives you information to hand if you need to use it at a later date to negotiate things with a customer. For example, you may use it to negotiate re-setting priorities if you find you have two conflicting deadlines. By keeping communication open, you may well find that you have one customer with a low priority project who is happy to be flexible about dates, giving you the opportunity to get a more urgent project finished and out the way first.

Keep one eye on the future

One of the main problems with managing projects concurrently is that if the projects are on a similar trajectory then you may have super-quiet periods and super-busy periods happening at the same time across all projects. This is an invitation for problems. For your own benefit, it is worth putting together a schedule of work across all your projects into a master program schedule, so that you can see at a quick glance if there are any future potential clashes on the horizon. This gives you the opportunity to arrange something in advance to cope with the busy periods. Perhaps you can reassign one of your projects to another project manager, or you can talk to one of your customers about rescheduling some of the work. Whatever option you choose, you can only do this if you have a very good schedule set out to see exactly where and when the problems will occur.

Rejecting or reassigning work

The title of this sub-heading could have also read: saying no. Sometimes, the best course of action is to turn away additional work so that you can concentrate on the ones you already have. This may not be a popular move but it is always worth considering;  your status and your career progression within an organization will benefit more from performing well against the projects you are responsible for rather than attempting to do many things and once and doing them badly. If you are stretched too thinly you won’t be able to give projects the attention they need, so learn when to say no.


Managing multiple projects can be hugely challenging for an individual. A project needs someone who can oversee it at a high level whilst having the capacity to jump in with two feet when things get complicated. That becomes harder to do when faced with multiple projects.

In order to maintain a consistently high performance across all the projects you are managing, don’t ignore the warning signs that you have too much on. If you do, plan a strategy for handling that in way that doesn’t compromise your performance across any individual project. 

Brought to you by PMLink.com. Author: Lauren Lambie

<![CDATA[How to win over an unhappy client on your project]]>Wed, 04 Sep 2013 14:48:58 GMThttp://www.pmlink.com/blog1/how-to-win-over-an-unhappy-client-on-your-projectPicture
Sometimes, a project manager must deal with a disgruntled client. They may be unhappy with one thing or many things, but if their feelings are strong enough to make a complaint then that complaint needs to be properly and fairly dealt with.

Unfortunately for project managers, complaints are not a rarity in the world of project management. It can seem very unfair to get criticism on a project when in the majority of cases a lot of hard work has gone into getting it successfully delivered. However, the reality is that you may be working with a client that is not happy with what they see. How do you deal with this situation in a way that is suitable for both parties?

Review the situation objectively

The first and very human reaction to a complaint is to become defensive. It doesn’t make sense to us that a customer would be unhappy. After all, we’ve been working hard getting their project delivered.

It is hard to see someone else’s point of view when you are in the midst of a complex, face paced and stressful project. Criticism may feel like salt rubbed in an open wound. However, to handle the situation properly you really need to be able to take a step back from your feelings and analyze the complaint objectively.

Try and get the complaint in writing and take time to read through it carefully, taking a step back from your personal feelings about the project. Have a look at the words they use and have a look at the statements they make in the complaint. Try to find a common understanding of what has caused the customer to become so dissatisfied.

It’s not personal

Even if you as the project manager come under direct criticism, it isn’t actual personal. Unfortunately for project managers they front a project; they are the face of the brand. Despite the efforts you may be going to behind the scenes to do things right, if there are errors they will fall to you to take responsibility for. So if the criticism is directly at you personally, try to take it on the chin.


Once you have your own assessment of what the problem is there is no better way of addressing it than talking directly with the customer at length. Arrange a time with them away from the project meetings, and without a large audience. Meeting in person is a better than talking on the phone as it allows you to read body language and also use your own body language – smiles, nodding, open relaxed arms - to diffuse a potentially tense situation between the two parties.

The key to this meeting is simple: listen, don’t talk. Allow the customer to open up to you about what the issue is, and explore some of the reasons behind why they might have that perception of the project. The purpose of this meeting isn’t to defend your project, but just to hear what you customer has to say as openly as possible. The customer will appreciate the fact that you are taking the time out to take their complaint seriously and this goes a long way to rebuilding a relationship.

Be honest

Honestly builds trust between you and the customer. Openness about what you are doing and why you are doing it will reassure the customer that your words are not just ways of placating them but that you are giving them a true, accurate and fair view of the project. If, for example, you have had to make a difficult decision about the project, explain why. Honesty will help the customer understand things from your perspective, and that will help in rebuilding the relationship.

Be flexible

Quite often, relationships with customers break down because there is a wide gap between what they want and what you can offer them. It can be a struggle for a project manager to close that gap.

However, even if there is a requirement of the customer’s that you are having difficulty fulfilling, there may be other avenues on the project for you to explore where you can offer them some added value. This shows flexibility, and by demonstrating that you are prepared to be accommodating with the customer will be seen in a positive light as its one of the biggest qualities customers want in a supplier.

Be responsive

Make sure you always follow up a complaint in a timely manner. In your follow up, reiterate back to the customer what you perceived their issue was. This shows you have understood and listened. Identify key faults that need remedying and put in place an action plan for dealing with them. This shows a level of proactive handling of complaints that will give the customer some confidence back.

Learn from mistakes

Use complaints as a way of doing things better in the future. Once the complaint has been dealt with, look at how you could avoid such issues in the next project. Complaints can be good opportunity to improve the way you do things as a business and within a project. Every project you do should be an improvement on the one before it. Think of things from that angle, and you don’t have to think of complaints in such a negative way; they can have a positive outcome. 


Complaints are never enjoyable to hear. If you get a complaint, it means something somewhere has gone wrong. What is important is not to dwell on the problem but look at how to make things better, and bridge the relationship with the customer. By doing so, you can build that trust and develop a long term relationship that lasts beyond the completion point of the project.

2013 © Copyright PMLink.com. All rights reserved.

<![CDATA[Project Management 2.0]]>Thu, 29 Aug 2013 01:46:23 GMThttp://www.pmlink.com/blog1/project-management-20Picture
Project Management 2.0 is a different take on project management that was come into thought based on Web 2.0 technology.  What does it mean?  Is it different than what you’ve been doing?  Do I care about it?  What are the pros and cons?  Those are some of the usual questions that arise when this concept is presented.  Let’s discuss.

What is it?

Project Management 2.0 isn't really that significant of a change from regular project management.  What it is truly about is the ability for distributed teams to collaborate on projects.  The concept of a geographically dispersed team tied together with Web 2.0 technology.  PM best practices are still important - they still apply if you want to give your projects and teams the greatest chance for success.  What's really different is the level of complete control the project manager has over the status of the project through collaborative tools and the amount of collaboration that can happen on the project.  

There are understandably some perceived pros and cons associated with the concept of PM 2.0.  Everyone has their argument and many aren’t interested in change or turning over control to traditional practices.


As mentioned, some PM camps see turning over areas of control to the project as a bad thing. When our teams are traditionally becoming more dispersed, this is actually a good thing.  Team work is as important as ever, but we must do it in a different way in order to be productive and responsive to what must happen on our projects. Involving the team in project status management and ownership of task status is a good thing in almost every instance.  Responsibility for collaborating and maintaining up to date project information on tasks breeds stronger ownership of those tasks and for the goals and missions of the project as a whole.  The project manager still retains overall ownership of the project schedule and project oversight, and must ensure that the integration of key project management information into a central repository is actually happening – nothing changes there.

Collaborative project management is also a green concept.  Using collaborative tools such as web-based ‘in the cloud’ project management and business tools like web-based PM software, wikis and knowledge sharing sites, and social media avenues like closed Facebook groups and Twitter to share information with team members and customers allows for more online work and remote management.  Travel for ‘onsite’ meetings is decreased and printing of hardcopy schedules and status reports is decreased. 


One major concern organizations have over PM 2.0 and the ability for it to be scalable to large projects.  Many corporations still feel that a desktop solution with an onsite project manager or a fully onsite team is the answer to control, productivity, management, and customer service and satisfaction.  Reality tells us, however, that it can be very productive.  Many professional service organizations that are producing on project engagements for customers around the world have gone to a virtual team concept necessitating PM 2.0 type project management and collaboration as a means to remain productive and proactive.  In those cases, relying on old school project management processes could cause failure and definitely would make it difficult for the PM, customer and team to have up to date project status and task information.  And without that, success is extremely difficult.  This is true for $20,000 projects as well as $20 million projects.  Two-month engagements as well as two-year engagements.


Is PM 2.0 good or bad?  I believe it is good, it is here today, it is necessary, and it is a likely and necessary transition – in today’s business world – from more traditional project management methodologies and communication practices to what best suites our project needs and our customers in today’s world.  As I mentioned, best practices are still best practices.  Those still must happen.  Communication is still the most important responsibility for the project manager.  And with organizations serving customers globally now rather than just locally, collaborative concepts that Web 2.0 and PM 2.0 technologies bring to us must be adapted and coordinated into the way we do business.  Our customers expect it and we must deliver.

2013 © Copyright PMLink.com. All rights reserved.

<![CDATA[Dealing with the Loss of a Key Project Resource]]>Wed, 21 Aug 2013 15:05:02 GMThttp://www.pmlink.com/blog1/dealing-with-the-loss-of-a-key-project-resourcePicture

There’s no denying that the project manager is the leader of the project and usually the most visible member of the delivery project team.  They are the primary customer-facing individual and replacing them is like replacing the coach on an NFL football team or a major league baseball manager.  It’s a highly visible move and very significant.

But what about the rest of the project team?  They are visible.  Often, on an IT project, the business analyst or the technical lead become just as visible if not more so than the project manager once the project moves from ‘planning’ to ‘doing.’  Replacing one of them can be like replacing your staring quarterback mid-way through the season.  It may help or it may hurt, but it will definitely change the team chemistry and it will definitely affect how the other side reacts and responds…in this case the other side being the customer.

So how do you deal with such a major change at mid-stream on your project?  There are definitely several things to consider:
  • How will it affect team chemistry?
  • How will it affect the comfort level of your project customer?
  • What will happen to the resource’s tasks in progress?
  • Will the project budget be affected?
  • Is the right replacement skill set available in time to make a smooth transition?

These are all real concerns and none can be taken too lightly.  However, you are to the point where you have no choice – no method of negotiation – to keep the resource and you must align all actions with moving forward and finding the right skill set as quickly as possible to replace the outgoing resource.

When this happens it’s best to follow three key steps to make the transition as smooth as possible for everyone involved…

Inform the project customer.  The first thing to do is to inform the project customer that a change will be made.  We’re assuming here that it is a high-profile resource on the team so there’s no easy way to do this without the customer feeling a great deal of impact.  Take it to the customer, explain the situation and outline with them the steps you are taking to find the right replacement.  This is all about the comfort level and confidence level of the customer.

Work with your senior management.  If you’re working in a matrix organization, then someone takes the resource requests and turns them into real resources.  You must work closely with that person to find the right resource because you’re not dealing with a new project – you’re dealing with a customer who has an existing relationship with a key resource you are losing and you’re in grave danger of losing a lot of customer confidence if the transition is handled poorly.  Work with this resource manager to get the right resource as quickly as possible.

Begin the transition.  How you onboard the resource can sometimes be as important as the resource itself.  It’s best if you can slowly transition with the new resource shadowing the outgoing resource for 2-3 weeks.  This is usually the best way to keep customer satisfaction at its highest.  If this is not possible, then the weight of taking over tasks and transitioning the new resource into the project successful falls to the project manager and the rest of the team.  However it’s going to be done, the key is to be open and honest with the customer about how the transition will be taking place and who will be responsible for the outgoing resource’s tasks during the transition.  At this point, over-inform, rather than under-inform, the customer.

2013 © Copyright PMLink.com. All rights reserved.

<![CDATA[The Reality of Project Integration Management]]>Thu, 15 Aug 2013 08:56:28 GMThttp://www.pmlink.com/blog1/the-reality-of-project-integration-managementPicture

The concept Project integration management is a key skill that is the tightly woven into the PM industry standard processes laid out by the Project Management Institute (PMI).  As defined by PMI, project integration management are the processes and activities needed to integrate the various elements of project management, which are identified, defined, combined, unified, and coordinated within the Project Management Process Groups.

Within the project management body of knowledge (PMBOK) guide, project management processes are presented as discrete components with well-defined interfaces.  That’s nice in theory.  However, in reality – most project managers understand that project processes, components, tasks, and deliverables actually overlap and interact in ways that are never really dealt with in the PMI standards guidebook. 

Primarily, project integration management is concerned with ensuring that the elements making up a project are properly coordinated so that project goals are achieved.  The key is coordination, integration, and efficient team work.  Using project integration management, all the pieces of a complex project plan need to fit together achieving a sort of balance between project time, project cost, and overall quality.  The project manager, therefore, is left with the responsibility of handling the chores of integration management while understandably needing to make tradeoffs between competing or conflicting project (and executive management) objectives.

Most experienced PM practitioners know there is no single way to manage a project.  They apply their PM knowledge, skills, and processes in whatever way is necessary to achieve these project objectives and – ideally – finish with a successful completion of the project or projects they are managing.

Of course, the project manager has tools at their disposal to do this.  Tools and templates exist for managing project budgets, capturing requirements, building test and use cases, and creating many project planning deliverables (such as design documents, communication plans, risk management plans, project charters, etc.).  There are boundless ways to manage resource usages and prepare resource forecasts and there are now hundreds of project management task scheduling tools in existence – many free – so, gone are the days of being tied to Microsoft Project as the PM’s only real option for managing teams, tasks, deliverables, and the customer.

But what are we really doing?  Will tools make the project manager successful at integrating all of the tasks, information, and processes within a project to arrive at a successful project deployment?  No.  Will PMI certification ensure that this will happen?  While it may help by giving a project manager nice tools and a knowledge baseline reference to ‘get it done’ the answer is still really ‘no’.  Projects don’t flow perfectly.  They often aren’t well defined.  It takes experience across many projects, it takes a project manager who can make good decisions on the fly, and it takes a leader who is grounded yet flexible, to successfully deliver on projects that are often subject to requirements changes, moving timelines, and pressure from outside entities that weren’t initially part of the project plan. 

Focus on the end goals of the project and proper utilization of the resources available – including the skilled project team and willing project customer – are key ingredients to project success and the successful integration management of all the deliverables, information and processes on any given project that flow from one phase to the next.


As stated earlier, project integration focuses on the streamlined flow of information, activities, tasks, and deliverables from phase to phase and process to process.  The reality of the projects we all manage on a daily basis is that there rarely – if ever – is a streamlined flow.  The challenge for the project manager then, is to manage projects with the real-world mentality and viewpoint, being able to adjust, coordinate, and control overlapping deliverables and information flows and handle competing and conflict requirements and constraints.  Communication, as always, is key, and information dissemination to the team and customer is essential.

2013 © Copyright PMLink.com. All rights reserved.

<![CDATA[Dealing with Problematic Team Members]]>Fri, 09 Aug 2013 01:43:43 GMThttp://www.pmlink.com/blog1/dealing-with-problematic-team-membersPicture
Managing your team should be easy because you’re dealing with trained professionals, right?  But that's not to say there won’t be difficult personalities along the way.  Our project resources are skilled professionals…with egos.  Each has their own unique talents that they bring to the engagement.  Likewise they each come to the table with their own unique experiences, behaviors, attitudes, and beliefs about how things should be done.  

Each team member presents a different challenge to the project manager.  I'm not saying you'll always have control issues with project team members on every project. Many projects can go off without a hitch in terms of project team members’ behaviors, compliance, and cooperation.  However, sooner or later you will encounter a situation where your authority is challenged or conflict arises with another project team member or a team member just isn't following through on the tasks assigned to them and they are not focusing well on the project as a whole. What you have is a control issue.  You're the project manager and you've now lost some degree of control over that resource or your project team in general.  That is definitely not a good thing and you must correct the situation quickly if you hope to maintain your reputation as a good project manager and leader in your organization.

In order to keep your project on track, you must take swift action.  There are three general steps to take, in order, to resolve the situation or remove the problem behavior: a one-on-one meeting with the problem team member, a meeting with that individual’s direct manager, and removal of the problem team member from the project, if necessary.  Let’s examine these three in more detail…

Meet with the resource

As an experienced leader, you must know that your first and best course of action is to go directly to the source of the issue – the project resource that is causing harm to the team and the project.  Discuss the situation with him, let him know – once again – who the project leader and primary decision-maker is, and layout what the next steps will if be if compliance does not begin immediately.  How firm or friendly you want to be during this ‘session’ will likely depend on a few things:  how desperate the situation is, how much longer you have to work together on the engagement, how destructive his behavior has become, and how he seems to be reacting to your corrective intervention.  Hopefully, this discussion will resolve the issue and set his behavior back on the right course.  If not…

Meet with the resource's supervisor

The next step, if the first doesn’t work, is to meet with his direct supervisor.  After all, this is the person directly responsible for hiring him, firing him, and evaluating his performance.  Let the supervisor know there is a problem on the project and that this resource is still not falling into compliance even after you’ve had a one-on-one discussion with him.  Let him make the next attempt at corrective action.

Have them removed from the project

Finally, if the situation has either gone to far that the individual can no longer be trusted on the project or if the first two steps fail to correct the situation, then the only option left is to remove the individual from the team.  Put in a request immediately for a skilled replacement, discuss the situation with the project customer if they are not already aware of the problem, and onboard the replacement resource as quickly as possible.  It’s critical that the transition be smooth in order to keep customer confidence and satisfaction as high as possible.


You hate to go to extremes. It can be disruptive the team, to the customer and to the forward progress of the project. However, it is far worse to lose control of your project and the team as a whole and that's where you'll be heading if you don't take swift corrective action.  You must show both your team and your customer that you can keep the project on track in order to maintain their confidence and cooperation.  

2013 © Copyright PMLink.com. All rights reserved.

<![CDATA[Is the Customer Always Right?]]>Wed, 31 Jul 2013 21:02:44 GMThttp://www.pmlink.com/blog1/is-the-customer-always-rightPicture
You know how the old saying goes.  “The customer is always right!”  How many times have you heard that expressed over and over again by a disgruntled customer or friend who feels they received less than a fair deal from some vendor?  Now think about that in terms of a project engagement where tens of thousands of dollars and possibly even millions of dollars are at stake.  How do you think that paying customer feels about service and being told they’re not always right?

Usually the customer either comes with a set of detailed requirements or you must extract those requirements from them.  Either way, they definitely come with a problem that has necessitated the project you are about to embark on with them.  But are they right?  And should you point out that they aren’t if you’re concerned they’re going down the wrong path.  The answer is yes, definitely.  Here’s why…

They may be chasing a symptom, not the real problem

When the customer comes to you with the need, no matter how certain they may be of that need, it is still your job to ask questions.  Discuss the need with the project sponsor.  Meet with the end users to identify what they feel the issue or need is.  The real need may be deeper – the customer may only be coming to you with a symptom of the real problem.  If you don’t tell the customer they are wrong and solve their real need, you may be only putting a band-aid on the real problem and when that becomes evident, you’ll have a very frustrated and dissatisfied customer on your hands.

They may be selecting the wrong technology

Many times someone at the customer organization – possibly even the project sponsor – comes forward with a project and they are certain that a particular ‘latest technology’ is the perfect solution for them.  This is usually the result of something they’ve been told or have read about.  Indeed, that technology may truly be what is needed, but it is still the delivery team’s responsibility to dive into the detailed requirements for the project and verify that the technology the customer is requesting is really the best way to solve the problem.  Often times when the customer has pre-selected the technology for the solution, it is not the best technology to use and a red flag should be raised.

They may be asking for add-ons they don’t need

On the delivery side, we always want to avoid ‘gold-platting’ the solution.  When we gold-plate, we deliver add-ons that aren’t part of the requirements and they end up costing us on the delivery side and putting the project budget in danger. 

What we’re talking about here, though, is the other side of the coin.  The customer can be asking for add-on services or functionality as part of the solution that they don’t really need.  Indeed, the solution delivered ‘as is’ may meet their needs – such as providing a needed report through the basic implementation making it unnecessary for them to pay additional fees to have custom reports developed.  It’s our duty on the delivery side to identify those situations, alert the customer and work to keep the customer costs as low as possible.


The bottom line is that you as the project manager and your skilled project team are the real experts.  That’s why you’re being hired to work the project and deliver a solution.  The customer may have come into the engagement thinking they needed ‘x’ and you’re telling them they need ‘y’.  But it’s your job to tell them that and to deliver an end solution that meets their needs…whether it’s a cheaper solution than they anticipated or a more expensive one.  Then let them decide with you on how best to proceed.

2013 © Copyright PMLink.com. All rights reserved.