132 Comments

How Changing a Flat Tire Made Me a Better Project Manager

04/14/2017 by Brad Egeland Tags: , ,

Project Managers are organized in everything they do, right? Well, I can say that I’m not.

And when I was attempting to change a tire on our full-sized 12 passenger van… I learned that I’m even less organized than I thought. My little kids were helping… so at least that aspect was fun.

The worst part? Everything else. I hate redoing work more than just about anything else. And I’ve been an application developer and a project manager long enough to know that rework usually comes from poor or incomplete planning/communication. I try to avoid both, but in the case of my flat tire, I failed.

What should have taken me 30+ minutes with some advanced oversight and planning, took me about four hours and a lot of unnecessary pain, sweat, and aggravation.

Why? Because…

Continue reading “How Changing a Flat Tire Made Me a Better Project Manager”

132 Comments
76 Comments

Is Your Boss Trustworthy?

03/23/2017 by Brad Egeland Tags: , ,

This may seem like a simple question, but the answer is bigger than we think it is. We’ve all grown somewhat immune to the mocking of those in charge – you see the President of the United States and other world leaders mocked on TV and other media all the time. But really, what about the leadership of your company? Do you have confidence in them? Do you think they have your back? Do you feel like they’re leading you, your co-workers … even your customers in the right direction?

I think the answer for many of us is often ‘no.’ And that’s sad. Why is that … why do we feel this way?

Trust button set on highest position. Concept image for illustration of high confidence level trusted service or review.

Continue reading “Is Your Boss Trustworthy?”

76 Comments
144 Comments

Do you know what the REAL project is?

03/09/2017 by Brad Egeland Tags: , , , ,

Sometimes what you’re really trying to solve is a bit hidden. The customer may not see it and you might not at first glance either. But it is your responsibility to make sure you always go that extra mile to make sure you are addressing the real issue and not just a symptom that the project sponsor sees and what seems obvious to everyone.

Unknown opportunity concept as three dimensional text hidden underwater with a viral healthy tree growing on a small piece above water as a metaphor for success and motivation to search for hidden opportunities in business and life.

Sometimes there is more to a problem than what you can easily see.

It’s not always easy to truly identify what is the real project. On the surface, it seems obvious. The customer comes to you with ‘x’ need and you work with the customer on business processes and requirements and move forward with work on a solution for that customer. You have a project involves working to solve the customer’s identified need.

However, it’s not always that easy … and as the Project Manager, you must assume that the customer doesn’t always know what it is they want or even what their true need is. Identify that true need, and you’ll be building a solution that keeps the customer happy.

Get the big picture by asking the right questions

Problems and opportunities can arise almost anywhere inside or outside the organization. Problems are typically driven from within and frequently relate to improving organizational performance. For example:

Problem Solution
A department that’s overwhelmed with paperwork. Simplify procedures.
An organization that constantly faces the prospect of worker strikes. Improve management/employee relations.
An insurance company that has branch locations spread across a wide geographic region. Communicate effectively among branches.

Problems are generally regarded as negative. Opportunities may be viewed as their positive alter ego.

Opportunities are often driven by external forces. More common examples can be found in the areas of product development or product enhancement. These opportunities are often the response to a perceived need in the marketplace. In other words, sometimes a problem leads to opportunities.

Identify the true project

The term “true need” refers to the most basic problem to be solved. Identifying your project’s true need can, at times, be tricky. But it’s absolutely vital that you as the Project Manager understand what the true need is.

Why? Because many will judge you as a project manager by your ability to solve the original problem. Solving the original problem equates to satisfying the true need and you and your project team often have to dig to find out what that true need actually is. You cannot be certain that you’ll satisfy the true need unless you know what it is. The problem is that when you’re assigned to manage a project you may not be presented with the true need explicitly. Terminology can become confused: what’s described as a need may actually be the solution to a need.

One of the most reliable methods for uncovering the true need is to ask the right people one simple question: “Why?” However, as you seek to uncover the true need, you can expect to encounter some resistance.

Summary / Call for Input

If you ask questions rather than digging in and getting the project going, some within your organization may assume that you’re not moving forward. However, asking the right questions of the right people can often lead to some startling discoveries.

Readers – have you had many projects where the real need was buried and the customer was actually coming to you with a symptom? I have … and the end result would have been disastrous if my team and I had only delivered on the symptom rather than digging for the real problem. Please share your experiences.

144 Comments
25 Comments

Is the Project Worth Saving? (Part 2 of 2)

02/23/2017 by Brad Egeland Tags: , , , ,

In Part 1 of this two-part series on figuring out whether or not what we have viable project … we looked at what brings us to the go / no-go decision point and how we review a project from both a justification standpoint and a feasibility standpoint.

Now, in Part 2, we’ll consider how to:

  • Review alternative solutions for your project’s problem(s)
  • Identify the best solution for moving forward

Project Justification and Feasibility.

Once you fully understand the project’s goal and establish that it is justifiable and feasible, you’re ready to determine the best way to satisfy that need. (You may wish to review Part 1 of this series.)

Although I’m using the term “you,” proper execution of this step really requires the input of many individuals. If you’re fortunate enough to be involved at this stage of the project’s evolution, you should be actively working toward building a team that can work with you from this point on.

Identify Alternative Solutions.

The process of identifying the optimal way to satisfy the project requirements begins with generating a list of potential solutions. This process is made easier when these elements are included:

  • Do it in a team environment
  • Include subject matter experts and stakeholders as appropriate
  • Use brainstorming techniques
  • Limit further development to only reasonable alternatives

Choose the best solution for moving forward.

Obviously, you can’t pursue every idea identified through processes like brainstorming.

After soliciting all reasonable alternative solutions, the project team needs to pare the list down to only those that are worthy of further development, investigation, and definition.

It takes a team to develop solutions and reach goals.

You can reduce the list by comparing each alternative against predetermined criteria. This is where the Requirements Document begins to add significant value. The process for selecting the optimum solution begins by evaluating each alternative solution in terms of how well it satisfies the most critical aspects of the project requirements, such as budget constraints or strategic alignment.

You may also wish to use other requirements-based considerations, such as the likelihood of technical success or the anticipated impact on existing products. This initial screening will allow you to shorten the list of potential alternative solutions to a manageable number (I would recommend two to five).

At this point, the selection process becomes much more rigorous. Each potential alternative should be evaluated using two basic types of criteria: financial and non-financial.

Summary / Call for Input

Readers – how do you feel about this process? How does it match up with your organization? Do you have similar processes you can share and discuss?

Not every project is cut and dried and definitely a project – some have to be fleshed out and decided upon … is this really something we should be doing and is this the best way? If not … what is? Please share your thoughts.

25 Comments
79 Comments

Is the Project Worth Saving? (Part 1 of 2)

02/16/2017 by Brad Egeland Tags: , ,

In one of my past lives in corporate America, I worked at a very large, Fortune 500 engineering and aviation firm that featured a central Project Management Office (PMO). There existed a requirement for all project managers to go through the following exercise on the larger projects (not all of the smaller projects required a formal process like this):

  • Kickoff the project with the customer
  • Document high-level requirements with the customer
  • Ballpark a solution and an estimate
  • Perform a formal project presentation to a technology council

Two things to understand first before going any further:

  • Nearly all projects at this company for the Project Managers (PM) were internal
  • The Tech Council was made up of internal executives

The sole purpose of the Tech Council and the PM presentations was to ensure that the project was worthwhile taking on (since everything was internal and really represented a shifting of money from one department to another rather than actual income – except where costs were being saved) and to ensure that legacy technology was not going to be used in a long-term solution when that technology was planning to be phased out and unsupported in the near future.

So, in a sense, the Tech Council was basically a go – no-go decision point early in the project. Even though it was early in the project it was a good time to ask:

  • Is this problem worth solving?
  • Does a potential solution exist?
  • Are we going about this solution in the right way?
  • Does this fall in line with our overall company goals and mission?

Justification and Feasibility

Buried in these four questions is addressing the issues of justification and feasibility. You should deal with both issues before continuing no matter what customer base you’re servicing – internal or external. If not, you run the risk of wasting time and money on problems that should not or cannot be solved.

Woman says that she dreamed the answers to their problems.

Justification.

Particularly financial justification—is very difficult to assess at the requirements stage, because not much is really known about the project. Nonetheless, it’s wise to try to assess whether or not you can justify continuing the project. You may be able to do this by executing a simple cost vs. benefit analysis.

The benefit component is relatively easy to estimate: it’s the value of satisfying the need. In many cases, this is nothing more than calculating how much the problem is costing today. Estimating the cost of the solution is more difficult, because you’re not sure what you’re going to do or how you’re going to do it. One approach you may wish to consider consists of working backwards through the financial calculations. By doing this, you can determine the most you’d be able to spend on a solution. If none of your proposed solutions can be executed for less than that amount of money, the project will ultimately be unjustifiable—at least from a purely financial standpoint.

Feasibility.

This comes down to a basic question: Do you believe that a solution exists? In other words, can this problem even be solved? This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

Summary / Call for Input

In Part 2 of this two-part series, we will look at working to identify the best solution possible for the project need and whether it is feasible to proceed with the effort.

Readers – please be thinking about your own processes that you and your team or management go through to make project go / no-go decisions and be prepared to comment and discuss.

79 Comments
168 Comments

Creating Recurring Tasks within a Project

02/05/2017 by Jackie Dembinsky Tags: , ,

Schedules are living documents, so oftentimes we need to review them regularly to look at what has been done so far and make changes to what still needs to happen. One of the easiest ways to do this is to hold reoccurring weekly meetings.

FastTrack Schedule makes it easy to pick each specific date and time that our recurring tasks will happen, we can even create dependencies to and from these meetings to show how they interact with the other portions of our project.

Create Recurring Tasks

For today’s example, we will build a recurring task to represent our weekly status meetings. When we enter our task, we will create a zero-day duration to mark it as a milestone within our project.

  1. Input the Activity Name and initial Start/Finish Date for your initial meeting.Zero Day Duration
  2. Add a new row for your next meeting date:
    • Place your cursor after the Start Date (11/15/12) for our “Status Meeting” task
      – Windows Users. Hold down Alt and press Enter.
      – Mac Users.       Hold down alt/option and press Return.
      This will create a new line for data within the current row.
  3. In this new row, we can select the next specific starting date, whether it is on the same day of the week or a different day completely, for our Status Meeting.New Row within the Row
  4. You can repeat the above process as many times as necessary to show each occurrence of this Status Meeting during the duration of your project.Multiple rows within the row

Change Vertical Alignment of Recurring Task Milestones

Once we’ve created numerous meeting instances, you will notice that each milestone on the Timeline Graph will line up directly with its corresponding date in the Start/Finish Date column. If you prefer, we can change this behavior so all bars appear on the same, centered line.

  • Windows Users. Right-click or Control-click any milestone and choose Select All.
  • Mac Users. Right-click or Control-click a selected milestone and choose Align to Grid.

This will align all of your milestones to the grid of the row, which by default matches the alignment of the row number.

Row within row vertical alignment

Create Task Dependancies

We can also create dependencies between our tasks to show a realistic flow from meeting to meeting, and any steps that may occur in between.

Milestones have task dependancies

Contribute to the Conversation

Have you ever had a project where you needed to show recurring tasks, but entering each of them into a new row was too cumbersome and clustered to view? In your upcoming projects what are some ways you can make use of recurring tasks to better show the flow of tasks?

168 Comments
151 Comments

Handling the Blame Game

02/02/2017 by Brad Egeland Tags: , , , ,

A reader of one of my articles recently commented about people blaming others for failures on projects and workplace tasks. We all know he’s right … some of us may have been guilty of it ourselves once or twice … or had the finger pointed at us in the ugly blame game. But that isn’t very professional and it still won’t resolve the issues with the failed or failing project – something still needs to be done no matter who’s fault it is. Let’s look at the whole blame scenario and how we might react and resolve the situation.

Finding someone to blame the bad stuff on.

The reader states that some PMs have a tendency to blame everyone and everything else when things go wrong. He says that all too often he see PMs blame others (suppliers, team members, customers) or things outside of the project (like the economy or the weather or even the exchange rate).

Finger-pointing, placing blame on someone else.
He’s right. There are people in organizations – not just PMs – that do this all the time. And there are PMs – the ones in leadership positions on projects – who are pointing the finger constantly at team members and customers, often just to make sure that they still look good when it hits the fan.

Look in the mirror.

Continuing on, the reader states in his comment that a good PM looks in the mirror first and should be the first to admit the mistake. I agree completely, though admitting mistakes is very hard for some. As the PM, we’re in charge and everyone is looking to us for our leadership. The PM must be in charge and must be ready to take charge and certainly must be ready to take responsibility for things that happen on the project.

I’m not stating that a PM should take blanket responsibility for every bad thing that happens during an engagement. Not at all. Rather an approach of ‘let’s see what we can do to get through this issue together’ is a good course when the problem was obviously caused by something beyond the PM’s control. The PM should not be a martyr taking on all blame no matter who was responsible. Nobody really likes a martyr who takes the weight of everything on their shoulders, but nobody in their right mind is going to follow a PM who finger points when issues arise. No good comes from it and no problems are really solved by it … all it serves is to divide the team and that is a recipe for disaster.

How do you deal with this type of leader?

First, personally, don’t become one. Have you ever found yourself easily pointing the finger at someone else – even privately among your team members? I have, and I hate myself for it later. It can also be detrimental to your leadership position with your team members – if they see you as a finger-pointer in the blame game, then they will not be seeing you as the take-charge leader you need to be.

How should we deal with this type of behavior when project problems or failures arise? Here are my first thoughts…

  • Re-direct the discussion from finger-pointing to aggressive resolution (if you’re not part of the solution, you’re part of the problem).
  • Have an offline conversation with the offending individual about the negative aspects of that type of behavior and its effect on the rest of the team.

If the private discussion doesn’t have the needed effect on the team member, then take it to their manager and ask that they be reassigned and replaced on the team. Stop the cancer before it spreads to the rest of the team.

Call for input

Project managers and project team members … have you seen this in your workplace? I’m sure you have at some point. Was it on your project? How did you deal with it? How would you deal with it? Please share your own experiences and let’s discuss.

151 Comments
77 Comments

PM Oversight of the Project Delivery Team

01/26/2017 by Brad Egeland Tags: , , , , , ,

One key aspect of the responsibilities of the Project Manager (PM), of course, is his or her management of the project delivery team. This is where the real work happens, where the rubber meets the road and how the project moves productively forward. It is a lot of responsibility and takes some obvious skills and planning to do it right… beginning with getting the resources planned, through project kickoff, and on to the actual performance on the project.  Let’s discuss…

Business team of success pop art retro style. The joint work. Business success. The schedule of growth. the business staff. Firm

Good oversight leads to a team that works together and is successful.

Resource Assignments

Let’s assume the team is assembled by leadership within your organization. I’ve been in organizations where one person managed the PM Office and assigned PMs to projects based on availability, geographic location, and expertise, and another person managed the Business Analysts (BA) and made assignments to projects based on those same considerations.

The technical staff is usually managed by a Development Manager or CIO (or both) and the technical resource assignments are made based on availability and expertise and they are often not full project timeline assignments like the PM and the BA positions. Those technical resources are assigned as needed and as determined by the project schedule and resource forecast maintained by the Project Manager.

Kickoff

Prior to the Kickoff of the project, the PM distributes all relevant project and contract information to all assigned delivery team members. This would usually include, at a minimum:

  • Statement of Work (SOW)
  • Original resource hours forecast/budget as finalized by Sales
  • Initial project schedule as created by Sales for the customer
  • Contact information for project team members on both sides
  • Any relevant travel and expense requirements as mandated by the customer

In addition, the Project Manager and the Business Analyst are preparing heavily for the Kickoff Meeting with the customer and planning for the move into Exploration. Frequent, ad-hoc communication is happening at this point to coordinate efforts and ensure that both are on the same page.

Onboarding

Once Kickoff is over, technical resources will begin being assigned (as needed) to the project and the effort of managing the delivery team resources and forecasting for their usage becomes a more important task for the Project Manager.

As new resources are engaged on the delivery team side, four things must always happen…

  • Provide the relevant project/contract docs for review
  • Provide recent status reports and the project schedule for review
  • Provide the resource forecast for review
  • Hold a formal delivery team meeting to go over current status, key project info, and answer questions

Ongoing oversight of project tasks

Once the project is fully staffed and is moving from Exploration to Design and beyond, then the effort of overseeing the work of the delivery team members should be fairly straightforward. Maintaining proper communication and the structure that should already be set in place will help ensure that each team member is up-to-speed at any given time on project status and what is expected of them at that moment and for the upcoming weeks. Just to review, this proper communication/structure should be in the form of:

  • Weekly delivery team meetings
  • Ad-hoc delivery team communication
  • Weekly formal status meetings with the customer
  • Weekly delivery of and review of the revised project schedule
  • Weekly delivery of and review of the project resource/budget expenses and forecast

Summary & Call for Comments

If all of these items are well maintained and delivered to team members in a timely fashion, then everyone will be on the same page. The Project Manager must be well organized because usually the PM is dealing with delivery team members who have other projects to work on that are in various stages of implementation.

Your delivery team members must always be made aware that this project is critical and that you have a solid structure in place or you’ll lose them to other activities and you’ll have more difficulty re-directing their efforts back to your project tasks. It’s much easier to lose resources to their other critical activities on other projects than it is to reign them back in … so stay organized and fight to not lose their focus in the first place.

Readers – how does this match up with your experience and expectations? Please share and discuss any additional information you care to add. Thanks!

77 Comments
21 Comments

The Need to Negotiate with the Project Client (Part 2 of 2)

01/19/2017 by Brad Egeland Tags: , , , , , ,

Are you a skilled negotiator? Does negotiating make your hair stand up on end or does it drive something in you?

In Part 1 of this series, I discussed negotiations for Budget and Timeline impacts on your project. I identified that issues requiring negotiations on projects usually fall into one of three main categories: Budget, Timeline, or Scope.

For this article, let’s look closer at Scope negotiations and how best to handle them with your customer.

Scope Negotiations

We all know that scope issues can abound on any given project – especially if some loose ends weren’t properly tied up during the sales process. I think the Project Manager should be involved in at least a portion of the sales process. When I worked at Rockwell Collins (RC) in the late 90’s and early 2000’s, all the projects were internal for in-house business units – I WAS the sales process. As was the case with all the PMs at RC, I handled:

  • Meeting with the customer
  • Documenting the business need
  • Pricing the engagement
  • Finalizing with the customer
  • Presenting the proposed solution to a technology council for approval

Sorry … enough plugging for the PM role in sales … for now.

Man Hand writing Scope with black marker on visual screen. Isolated on white. Business technology internet concept. Stock Photo

Back to reality. Scope issues are a fact of life, they will always happen. When the customer says, “but I thought that was included,” you have to look at it from their side as well as your own. Do some investigation. Maybe Sales told them it was included? Maybe the line was a little gray? Or maybe you can see some bigger work that is coming down the line on the project in terms of scope and now is the time to negotiate.

At any rate, it’s about the give and takes. For most scope issues you’ll:

  • Draw up a change order
  • Identify the budget and timeline hits
  • Present the customer with the cost factor for adding the extra scope

If they balk, there may be some room for negotiation – for example, price the implementation of the new functionality but throw the training in for free. Of course, you may need senior management approval for this – another form of negotiation, possibly. Explain the need for customer satisfaction, retention, and referral, or possibly your vision for some bigger add-on work that you can see in the offing.

Another issue that can lead to major scope concerns and the need to negotiate is the lack of previously defined customer business processes or poorly defined customer requirements. As the Exploration Phase gets underway, this issue really can come to light – if it hasn’t already. As the PM, this is when I look for the opportunity to negotiate with the customer in terms of creating additional revenue for the delivery organization in the form of a Change Order.

It’s obvious at this point of the project that (for example) a two-week Exploration Phase is not going to cover everything that is needed. You’ll need to explain to the customer that:

  • More time and effort dedicated to Exploration is needed.  These additional hours and $$ should be in the form of a Change Order to properly record requirements and create a meaningful:
    • Business Requirements Document (BRD)
    • Functional Design Document (FDD)
    • Technical Design Document (TDD),
  • That the increased effort added up front helping the customer define their business processes and requirements will result in a more solid solution being deployed to the customer at the end of the project.

It shouldn’t be too hard of a ‘sell’.

Summary / Call for Input

I’m not sure any of us really thought we’d be negotiators when we entered into the PM field. But it seems to come up regularly on projects.  We’ve examined Scope Negotiations in detail here.

Readers – what are your thoughts on negotiations? Are you good at it? Have you found yourself in the negotiating role with your project clients from time to time?

21 Comments
132 Comments

The Need to Negotiate with the Project Client (Part 1 of 2)

01/12/2017 by Brad Egeland Tags: , , , , , , ,

Negotiation is a four letter word to some people, and a passionate love for others.  Is negotiation part of the Project Manager’s role?  It certainly is.  In fact, without realizing it, the act of negotiating things on a project probably infiltrates just about every role occupied on a project … but it’s certainly most prevalent in the Project Manager role.

Reasons for Negotiation

Let’s take a look at reasons the need to negotiate may arise on an IT project.

  • Functionality needed earlier than expected
  • Out of scope work that needs to be included in current timeline
  • Customer request for a different resource or skill set
  • Data management issues and who handles them
  • Customer training
  • Budget issue vs. Timeline issue

The list can go on and on … these are just a few of the ones that I’ve personally run into on my projects.

Generally, the issues fall into one of these three categories:

  1. Timeline,
  2. Budget or,
  3. Scope (Covered in Part 2)

Unless the PM is being micro-managed from above by executive management or the PMO Director, the role of negotiator – at least from a customer-facing perspective, falls to the Project Manager.

This is the first of a two-part series on the need for negotiations with the project client from time to time. In this first part, we look closer at Timeline Negotiations and Budget Negotiations and how best to handle each type with your customer. Part two covers how to handle Scope Negotiations.

1. Timeline Negotiations

Negotiations on timeline issues can take on many forms.  For me, the most common timing issue has been the request for functionality to appear earlier than previously expected.  While this can sometimes be a major headache depending on the project, I try to take the phased approach if it is appropriate.  By this I mean, negotiating with the customer on implementing functionality in phases.  To do this, I follow these steps:

  1. Review the request for functionality
  2. Discuss with the delivery team experts
  3. Re-work an alternate project plan to move the requested functionality to early in the timeline
  4. Document a narrative for the customer outlining what needs to be pushed to later in the project to make it happen
  5. Conduct a formal meeting with both teams to present the proposal

Generally, my presented proposal consists of:

  1. Restructured priorities
  2. Moving the needed functionality to an earlier point in the timeline
  3. Implementing the functionality
  4. Creating later phases for the remaining functionality

It may also impact the budget, but if it gets the customer the functionality they desperately need when they desperately need it, then they’re probably very willing to accept the budget change it requires (this has always been my experience).

2. Budget Negotiations

The most common budget negotiations I’ve run into have been either:

  • Higher-priced resources needed or requested on the project

If it is warranted by the project due to some undocumented needs by the customer, then I’ve often been able to ‘sell’ the customer on the higher-priced resource.  If it’s the other way around – meaning the delivery organization wrongly assessed the resource needs, then the push needs to be to get senior management to agree to give your project the more skilled resource and bill the customer the same lower rate.  As the PM, you still need to explain that to the customer – never miss an opportunity to gain additional customer satisfaction by letting them know you’re always fighting for them.

  • The need for some unexpected customer training

In the case of the customer training…  And it doesn’t have to be customer training – you can insert any one of a number of similar items here.  But for me, it’s usually been customer training.  The customer hasn’t realized the need for some training (usually due to a communication issue during the sales process), but it’s still needed and it isn’t cheap.  Work with the customer and determine options.  What’s worked for me, has been to coordinate with both the customer and the training department to price a training session on site for the customer rather than have the customer send everyone to the training department.  This results in significant customer cost savings while bringing in new streams of revenue to departments in your own organization.

Part 1 Summary & Discussion Questions

I’ve mostly talked about the need for external customer negotiations.   However, the need to negotiate also comes up regularly in your own organizations as you work to obtain resources, equipment, budget, and etc.  The good Project Manager draws on experience from a history of customer dealings to enable them to effectively negotiate for things on their project with everyone involved in it.

How have you dealt with Timeline and Budget negotiations? What has worked, or not worked?

Continue to Part 2.

132 Comments
« PreviousNext »