Skip to main content

Tag: Facilitation

How do you Implement Lean for Project Management

Written by Lisa Anderson on . Posted in Articles. 8 Comments on How do you Implement Lean for Project Management

FeatureOct19There’s no doubt that there is a vast amount of interest in lean principles.  I’ve had multiple client requests – both ones who are interested in doing the latest and greatest program that they think might be the answer to “all their issues” and those who are interested in implementing culture change.  I find that those clients who view lean as a culture change and are focused on long term fundamentals leapfrog the rest with bottom line results. 

In today’s new normal business environment, sales are lackluster and resources are scarce yet customers expect more for less.  Thus, the traditional avenues to success will no longer yield the same results.   Instead, we must try new approaches and “think smart” to thrive in the new normal business environment.  As project results can be a significant contributor to the bottom line, there is no better time to think about how to succeed in new ways.  Why not incorporate the lean concepts that make sense to project management? 
In my experience as a business consultant, a not-for-profit leader and a former VP of Operations, I’ve found that there are several lean principles which align with project management success.  The top three include the following:  1) Focus on the customer.  2) Eliminate waste.  3) It’s all about the people.

  1. Focus on the customer:  Similar to implementing lean in manufacturing environments, first take a step back and think about the customer.  Who is the customer of your project?  Or, said another way: who will benefit from the project? 

For example, one of my client projects is focused on reducing the past due metric. In this case, the customer connection is obvious – the fewer customer orders which are past due, the better service the customer will receive.  Yet, even in this case, truly understanding what the customers’ value is important.  Would the customers prefer a delivery date that is achievable and reliable or would they prefer a shorter lead time with less reliability?  I’ve yet to work with a client who didn’t have customers who value different aspects of service higher than other customers.  Find out and optimize based upon what each customer values. 

In another example, another client project is to implement an inventory management system.  Who is the customer?  There could be several:  The end customer will likely receive better service with improved inventory accuracy.  The CEO will likely improve profitability as the inventory management processes are optimized.  The CFO will be much better equipped for a financial audit.  And the list goes on.  Although it is helpful to brainstorm all the benefits, it is vital to understand which is of value to your customer.

  1. Eliminate waste:  There is a plethora of waste in project management.  First, look for waste.  Taking a step back, since it’s unlikely we’ll be looking for machine waste in project management, we should think about the best definition.  I like the following – waste is that which doesn’t add value to the customer (and that which the customer is willing to pay for). 

It is interesting how often we become used to waste and don’t see it anymore.  Thus, you need to put on a new pair of glasses to see the waste all around you.  Can you accomplish the project in a fewer number of steps?  Are you following up on every task or focusing attention on the critical path?  What will provide a return on investment?  Are you asking the project team for input and ideas to eliminate waste?

  1. It’s all about the people:  Last but not least, those who succeed with lean initiatives understand that it’s all about the people.  In essence, it is not an event; it is a culture change.  Do you engage your people in the project?  Do you ask for their input?  Do you explain the project scope and its value to the organization?  Do you do what you say you’ll do?  I find this is much harder to do than it sounds yet it is a secret to unleashing your project talent.  In my experience, an exceptional project team with a so-so project will beat a so-so project team with an excellent project every time!

Implementing lean for project management doesn’t require cash, capital or extra resources yet it can ensure that your project is delivered on time, on budget and with dramatic results.  Although it is a good idea anytime, it is a must in today’s new normal business environment.

Don’t forget to leave your comments below.

Agile Project Management—Engaging Your Customer!

Written by Robert Galen on . Posted in Articles. 2 Comments on Agile Project Management—Engaging Your Customer!

RG2The agile methods come at software development by challenging many of our status quo practices. The first one is the engagement level of the ‘customer’. It’s my experience that most waterfall or traditional projects allow the customer to disengage after they start the project and provide an initial version of the requirements. After some time…later…they appear at the end of the project to receive their prize. Usually they’re disappointed in the end result—finding the functionality not living up to their original vision & expectations.

This sort of “end-points” behavior leads to many project failures due to a lack of clear communications, misunderstanding, and missed expectations.

But it has a simple solution. The customer should stay engaged during the entire project. They should be available for trade-off discussions and for demo’s. They should provide ongoing feedback on interim deliverables. They should even understand the teams’ capabilities and implementation challenges. In a word, they should become a “partner” to the team and not simply a “stakeholder”. They need to have continuous skin in the game if the project heads south and they need to be a part of trade-off and scope adjustment decisions.

The agile methods have several ceremonies or tactics that are intended to draw the customer into the team; to foster their inclusion and to gain their insights. In this post I want to review and emphasize the importance of these practices and the need for overall customer engagement.

Backlog Grooming

You all know that a prioritized backlog of work items (features, tasks, key functional and non-functional requirements) is what drives the agile ‘machine’. The list is dynamic in nature with items being added, removed and changed nearly continuously during the lifetime of an agile project.

Many represent the central nature of the backlog as a pyramid or iceberg. It follows then that at the ‘tip’, the highest priority items are found. They are also defined at the clearest and finest level of granularity. In other words, these items are ‘ready’ for execution. The team has sized them and broken them down. They have talked about them several times as they’ve done this.

This activity is typically called ‘grooming’ the backlog. It’s where the team repeatedly revisits the backlog, refining it from multiple perspectives and getting elements ready for execution. The Scrum Product Backlog is not only a list of features, but it’s effectively a work breakdown structure for all of the work necessary to complete a product or project release.

By involving your customers and stakeholders in backlog grooming and making it transparent, you’re engaging them at a base level of requirement management and planning. Both are areas where your transparency can and should pay-off in increased interaction and feedback on the backlog—pre execution.

It also results in a better understanding on the part of the stakeholders on the level of complexity and difficulty that the team is encountering. I probably hear pushback 3-5 times in every grooming session around how easy they thought a feature would be to complete. Why, we almost do it now, so it can’t take more than an hour or so to extend the feature…right?

Then the team, usually patiently, tries to explain why the design is more complex and how the estimate for the story is extended by the “real world” they deal with every day. Or why a single day implementation might need three days of testing because of data security concerns. So having the customer involved in grooming and planning (next) can really help them understand why things take as long as they do, while also drawing them into powerful trade-off discussions.

Sprint Planning

Rarely does an approach to software development include customers and stakeholders in planning the project. At least not in the nitty-gritty details of the effort. But in Scrums’ Sprint Planning ceremony the customer is welcome to attend as the team considers the work and plans their execution.

The meeting has a two-phased approach. Phase one is focused towards the Product Owner sharing the sprints’ focus with the team. They review the body of stories targeted for this sprint and answer any late-binding questions the team may have about them. Quite often, the questions vary from specific behaviors to how the team might design and implement the feature set for the sprint.

Once phase one is finished and the team fully understands the work, they then dive-in and begin to break down each of the stories into work tasks. Keep in mind that these are ALL tasks associated with the work—for example: development, testing, design, inspections & reviews, documentation, etc. Every bit of work required to deliver the story to completion is identified by the team and the effort associated (hours) are estimated.

So you might ask, how does this help the customer engage? It allows them a view into the planning & execution dynamics of the team in order to deliver on their requests. They gain a glimpse into the level of difficulty associated with each feature—where are the hard ones, fraught with risk. And conversely, where are the easier ones.

They gain insight into the strategy the team will be using to deliver the features. Who will be working on which features and why? How is the team planning on handling dependencies and overall feature testing? How are they planning on handling risks? And if the team is operating as part of a larger group, how are they interacting with other teams on dependencies, integration, and collaboration?

In a word, the plans are totally transparent and open for discussion and adjustment. The team simply wants to deliver on its commitments, so constructive ideas are welcome—especially the empathy that stakeholders should realize by becoming part of the teams’ planning.

You see—software is rarely as simple or easy as most bystanders believe.

RG1

Daily Stand-up

All of the agile methods have the notion of a daily team meeting for sharing progress, challenges and making real-time adjustments to the teams’ committed goals. In Scrum this is known as the Daily Scrum and it’s where a customer can gain real-time insight into the “inner workings” of their agile team(s).

I remember a team implementing some features in an eCommerce application. To her credit, their VP of European Operations would attend the meetings whenever possible as they were developing the interfaces to Amazon UK. She would listen intently to the discussions, but wouldn’t interrupt the team with questions as she was a compliant ‘chicken’ in the stand-up meeting.

However, after the more difficult conversations in some of their daily scrums, she would pull me aside and ask me questions regarding what she had ‘heard’ in the stand-up. Were they in trouble? How could she help? And, could they adjust some of their scope commitments in order to assist the team? Were very typical questions she asked. In some cases, her concerns were unfounded. In others, they were absolutely right on.

The stand-up was her window into the teams’ work dynamics that she had never had before. No longer was she relying on written or e-mail status reports that were interpretations of progress. No! Now she received unfiltered, raw data from the team themselves. She encountered the highs and lows. She clearly saw the teams’ challenges and, more importantly, how they approached resolving them.

She didn’t need a report to tell her where the risks were. Instead, she viscerally understood them by interacting with the team. She also saw the opportunities present themselves where she could assist the team in making adjustments while still achieving their & her overall goals.

It was incredibly powerful and frightening at the same time. It enticed, no encouraged, no demanded her to engage as an ‘owner’ with the team.

Sprint Review or Demo

One of the core agile manifesto points is “working software over jabbering about working software”, and I paraphrased a bit here. You see an incredible emphasis in agile teams, and I think it appropriate, to discuss most of your designs, requirements, and product commentary while looking at working software. There’s literally nothing else like it.

In Scrum, there is a Sprint Review or demo ceremony at the end of each sprint or iteration. In the demo, the team is responsible for showing off their working software that was focused towards their established sprint goal(s).

This ceremony is a “big deal” in Scrum teams. At iContact for example, we have sprint reviews for our teams every three weeks. We have them in our largest conference room. We literally invite the entire company (yes, we’re relatively small) to the event. Usually over half of our C-level team is in attendance and the room is typically standing room only.

Each team takes its turn to demonstrate their efforts for the past sprint. Team members all get a shot at speaking to their efforts. The audience is engaged. Asking questions and providing immediate feedback on the functions and features demonstrated.

Often the feedback extends beyond the demo. Folks will follow the team back to their seating areas and provide additional feedback and/or ask to see a particular feature again. I often see our CEO whispering his reactions to our product managers during and after the demo as he guides the vision he’s personally looking for in our product.

But beyond feedback for our teams, it shares information with our sales, customer support, and account managers. They become familiar with what’s being developed in real-time and can communicate those “coming attractions” directly to our customers.

Wrapping Up

One of the keys to engaging the customer is showing them you’re listening to their feedback. That it matters to you and you’ll take relatively immediate action on it. This loop of (Listen To Feedback – Develop/Change Software – Demonstrate – Listen Again) is a wonderful device for agile teams to assure they’re on the right track.

It also draws in their customers. It engages them in the process because they feel more like a partner in the teams’ efforts. Now not all customers will embrace this behavior. Traditional customers will be taken aback and you’ll hear excuses—mostly that they don’t have the time for it. You’ll need to be patient and, over time, draw them into your efforts. Working software that demonstrates solutions to their most challenging problems can be…well intoxicating.

Agile project managers maintain their teams’ focus on the heartbeat of delivering value and work hard to PULL the customer into the fray. Why? Because it’s their software, they need to care, and you need their feedback. So just do it!

Don’t forget to leave your comments below.

Deliver Project Results by Engaging Employees

Written by Lisa Anderson on . Posted in Articles. 5 Comments on Deliver Project Results by Engaging Employees

FeatureAug10In today’s new normal business environment, sales are lackluster, cash is tight and material prices are squeezing margins.  Thus, those projects which will increase sales, reduce costs and/or improve customer service levels/ loyalty are quickly becoming #1 priority within the organization.  The companies who can deliver project results consistently will succeed.  And those who can accelerate the results while maintaining the quality of results will have the opportunity to leave the competition in the dust.  

What is the secret to success?  Engaged employees!  Have you noticed that those organizations with engaged employees not only perform better than the competition but attract top talent?  What could be more important in the new normal but to have engaged employees leading your projects – and to have access to top talent during the timeframe when long-standing talent is leaving the workforce as the baby boom generation begins to retire?

So, what are a few strategies to effectively engage employees?  The top three include:  1) A compelling vision.  2) Translate the vision into individual goals.  3) Become a feedback fanatic.

  1. A compelling vision – Engaging employees must begin with a compelling vision.  Although a paycheck is required, it is by no means a motivator.  So, what motivates employees to engage beyond the minimum requirements of their job or latest project?  It begins with the vision. 

For example, does the company help improve the human condition in some respect?  If you work for an adult diaper manufacturer, could the diaper you produce or ship more efficiently be delivered to your grandmother?  Or, if you work in aerospace, does your project somehow contribute to the successful flight of an F-17?  However, even if the vision is compelling, it is useless if not communicated effectively.

Of course, there will be industries that seem less obvious in terms of benefits yet there is always a reason for being in business – find out and make sure to communicate it.  Your employees want to be involved with a company and a project team that is going somewhere and provides value.  Begin with a clear and well-articulated vision.

  1. Translate the vision into individual goals – Once the vision is in place and communicated, employees will feel better about where they work but will not be engaged.  The next critical strategy is to translate the vision into individual goals.  This is much easier said than done – leadership is vital to success. 

It is not always obvious how each person on the project team can contribute to the vision yet this is where the “rubber meets the road”.  Begin at the high level as it’s always easier to tie the vision to high level objectives.  Expand from there.  Dig into how each person’s core responsibilities can affect the next level objectives.  There has to be a purpose for your project; otherwise, you should stop doing it.  Then, similar to the vision, it is useless if not communicated.  Make sure each person understands how he adds value and contributes to the vision.

  1. Become a feedback fanatic – As simple as this sounds, providing feedback rarely occurs.  The best practice for providing feedback is to give consistent and immediate feedback – both positive and constructive.  Do not wait for the end of the project or the annual performance review!  Who remembers so far into the future?  No one.

Be visible and proactive.  Look for opportunities to provide positive feedback.  Amazingly, I’ve yet to find an example where well-thought out and specific positive feedback doesn’t motivate employees more than a raise or bonus.  Don’t forget to say thank you!  Simple yet often missed.  And, do not put off constructive feedback.  Be respectful and collaborate with the employee on how to improve.  Sometimes constructive feedback can motivate more than positive feedback as the employee understands you are invested in his success.

Engaged employees will deliver dramatic project results.  Have you ever seen unhappy employees deliver exceptional customer service?  It requires zero capital investment yet can have a profound impact.  Give the top three strategies a try, and watch your employees become engaged.

Don’t forget to leave your comments below.

10 Key Success Factors for Application Implementation Projects

Written by Brenda Hallman on . Posted in Articles. 88 Comments on 10 Key Success Factors for Application Implementation Projects

There are many factors in an application implementation-related project that over time have proved to be key contributors to the success of such projects.  This includes items that may seem obvious, such as solid testing, communication, and involvement by key staff members, but these are often under utilized in favor of saving time.  When projects skimp on these key items, it is likely to result in:

  • delays in meeting project dates,
  • disagreements on what the project is expected to deliver,
  • difficulty solving issues,
  • confusion on direction, work requirements, and status of the project,
  • lack of buy-in from team members and the end users,
  • additional stress and demands on the time of team members and end users, particularly near the end of the project,
  • less satisfaction from the client on the final delivered product.

{loadmodule mod_custom,ad 300×100 Large mobile}

Many types of documents, templates, tools, and strategies exist for managing a project.  This article will focus on 10 items that represent supported concepts in the project management industry and should, at minimum, be utilized for all significant application implementation projects. 

Related Article: A Project Manager’s Guide to User Experience

1. Solid contract with software provider

A verbal agreement won’t cut the paper it’s written on. Get it in writing! If a contract is already completed and these items have not been included, you should work with your vendor to reach agreement on these terms.  Additionally, you should work with your organization to see that these items are included in future contracts. 

The components that you will want to have well defined are:

1. a payment schedule,

2. outline system performance criteria,

3. penalties related to performance issues and delivery delays,

4. documentation requirements,

5. training, which is provided,

6. inclusion of a test system, and possibly a training system,

7. issue resolution/turnaround time/escalation policy,

8. and vendor support during and after the application live event.

Having these items defined contractually is an assist to the project manager.  It will provide you with agreed-upon criteria allowing you the leverage to hold your vendors accountable to their deliverables. 

2. Involvement by key staff and resources

The organizational structure of those involved in the project is a significant indication of the success of a project and is one of the first things you want to have in place to start the project.

Make sure to have a:

  • Project Sponsor. 

This person should be a senior manager head of the Steering Committee.  They will be the source who authorizes the project, ultimately ‘owns’ the project, and sources the funding for the project. They would not and should not be a member of the project team. 

  • Leadership Committee. 

This leadership committee is responsible for following the status of the project, representing the project to their peers and senior management, and assuring all of the appropriate parties are involved.  This group will make any decisions that the team cannot determine, they will assist rectifying business issues and with escalation of problems including to vendors or internal staffing. Use these people!  They are there for you.

  •  Project Team. 

These are the folks that are performing the work for the project. You may have several teams, or workgroups, with different focuses.   

  • Project Manager. 

Hey!  This is probably you! The Project Manager is responsible for overseeing that the work is getting completed as expected on schedule.  They manage any deviation from the scope or schedule to get the project back on track.  They are generally responsible for planning and often own and complete the project documents (such as the scope, staffing plan).

Additionally, consider the following while staffing the project team:

  • Be certain to include individuals who know the business.  If there are different aspects of the business involved in the project, include a representative from each of these areas.  These individuals will often serve the most benefit as project team members who are active in identifying processes, business needs, and performing testing and training. 
  • Consider a ‘superuser’ strategy.  This works well where individuals are identified early on in the project to serve as business/application experts.  They may be those who perform testing and training as well as first line support for end users.  These users can often serve as project team members.
  • A Project Staffing Plan should be completed to include the names of the individuals involved, the committee or teams that they are serving on, and the roles and responsibilities of those individuals and teams.  All team members, and their managers, should approve this plan so there is agreement on the expectations. 

3. Plan how the project will be managed

Create and share a Project Management Plan that will document how the project will be managed.  This should be agreed upon with the resources and management.

  • Document how changes will be handled, especially those that impact the scope, dates, budget, or resources.
  • Document how issues will be managed and escalated.
  • State how the schedule will be managed.
  • Include all methods of communications that will be used for the project.           
  • Once you review this with the team, you will likely be the sole audience for it.  Really, it’s not that entertaining and you shouldn’t expect others to be interested in it.  However, you will utilize the content to guide how various aspects of the project are to be managed and you may also refer to it if a deviation occurs where you need to reference the agreed-upon terms.

4. Define and agree upon the project scope

Write a project Scope, state what is and what is not included in the project. 

  • Document deliverables and assumptions.
  • Refer to any requirements that were gathered.  If no requirements were gathered, meet with stakeholders across the board to determine their requirements so that expectations can be documented and agreed upon.
  • Include Milestones, which are significant events, with their due dates.  Remember that “TBD” is not a date!
  • All project team members should understand the scope.
  • It is important to get formal approval from the Steering Committee on the scope before the project execution phases begin. 

5. Development and management of a schedule

A Schedule is the central tool to managing a project’s activities and keeping on track.

  • Develop a schedule that documents the tasks that need to be done to complete all of the deliverables outlined in the scope. 
  • Be sure to include dependencies, but not the work associated with those dependencies, on items that are outside the scope of the project.
  • Assign names and due dates to each task.  Does that seem obvious?  While it is probably obvious, it is not always done.  Oh, “TBD” is not a person either!
  • Items that risk a delay should be done as early as possible.  This may include such things as ordering hardware or scheduling training.
  • Highlight tasks that are milestones from the Scope. This will allow better tracking and reporting of those milestones.
  • Note items that are on the critical path (these are tasks that if delayed will delay the rest of the project).  Special attention should be paid to these tasks to keep the project on time.

6. Management of an Issues List

Having one central repository to log issues is invaluable. 

  • Each issue should include a clear description, name of who is assigned to own/resolve the issue, a due date, status, and priority.  If an issue is being resolved by someone who is not on the team, it should be assigned to a team member who is responsible for tracking the issue.  Another note, “ASAP” is not a date!  Your ‘soon’ and someone else’s ‘soon’ can be two entirely different times!
  • “High” priority should be reserved for those issues that, if not resolved, could impact the stability of the application, the integrity of the data, or completion dates of critical tasks and events. 
  • Track issues actively (daily or weekly).  Include new ones as soon as they arise.  Log updates to each issue as they become known. 
  • Document issues even if they are likely to be easily solved.  Those tend to be the ones that get away and should not be ignored.
  • Share the issues list with the entire project team; get updates regularly from the owners of the issues as well as team members who may have items to add.

7. Solid Testing

Testing is critical to understand how the application will work in the installed environment, if it performs according to expectations, and to identify any problems with the software or processes so they are addressed prior to the live event.

  • Document what type of testing must be done (i.e., database conversion, data flows, user front end, business flow).  Include who will be involved in testing and how it will be performed. 
  • Write Test Scripts that detail all scenarios that could occur.  Business end users should be involved in this as they are most likely to understand all aspects of their business. 
  • Test items that are standard operations as well as those items that occur infrequently.
  • Conduct user testing with staff members who are familiar with the business for which the application is designed.  They should be validating the application for their business.
  • Allow time in the schedule to retest anything that did not work initially.  If any changes are made to software or setup, run through most tests again to assure there is no negative impact in other areas.
  • Determine security access, setup, and test user accounts prior to live.

 8. Training Program

Proper training is essential to assure that end users are prepared to use the application.

  • Identify all users early on in the project; this will help to confirm all possible scenarios are covered and all users are part of the project communication.
  • Training will be optimized, and sessions better received, if individuals who will have similar use of the application are trained together. Also, if there are users who are not familiar with computer systems, consider holding a general knowledge training first.
  • If the possibility exists, allow the users to have access to the test or training system before the live so they can practice.  Consider providing practice scenarios for this occasion.
  • Create a Tip Sheet that is easy to read and highlights the top items a user would need to know.  This can be useful for the live as well.

9. Preparation for Live Event

A review of all deliverables and tasks should occur weeks before the system is ready for production use. 

  • Anyone involved in the project should verify that all tasks are completed, or will be completed as scheduled, for the live event. 
  • Issues should be scrutinized at this time so a decision can be made regarding their potential impact to the live.
  • Assign staff who have a good understanding of the application and business to assist users during the first days of production use.  Establish a central call number that is staffed with individuals who can track, solve, or escalate issues.

10. Communication

Communication is one of the key items recognized as leading to a successful project.  It should also be noted that in projects experiencing problems, communication is often reported as lacking.  So last, but certainly not least, are tips to improve this valuable activity.

  • Keep committees and teams informed.  The Steering Committee should be meeting at least once a month. The agenda should include a review of an up-to-date status report and focus on any issues or concerns with dates or deliverables. This committee should not be concerned with the work outlined in the schedule, but rather the higher-level milestones.  The same holds true with issues.  Only review high-priority issues that may have a negative impact on the project and not the entire issues list.
  • Team meetings should occur weekly or as needed.  Even a short conference call meeting can be effective to get everyone together. Those involved will have an opportunity to state something that may otherwise be overlooked. Status on the work being completed can be shared with all team members to assure everyone is in line with what is expected.
  • Monthly or weekly Status Reports should be completed and shared with all involved individuals.  The status report should include: status of milestones, recent work completed, what work is to occur next, high-priority issues, and changes to budget, scope, schedule, or resources.  This should not be a detailed account of activities but rather a summary.
  • Users should be informed of the progress of the project as it evolves.  Try to present them with demonstrations of the application in advance.  Distributing emails or newsletters are a good way to get information out and often receives a positive response.  End users do not need to know about problems, but the more they are involved with the status of the project, the more they will accept the change.
  • Remember that communication is vital to the success of a project.  It allows for establishing expectations and keeping everyone informed.  Only provide recipients with information they require and do not burden them with excessive details.  Different audiences may require different formats or content.        

Consider the above items when approaching your next project.  Although this article describes some instances specific to application-related projects, most strategies will be valuable to any project.

Don’t forget to leave your comments below.

Brenda Hallman has over 15 years of experience in project management, most recently in the Project Management Office at Main Line Health where she is responsible for standards, tools, mentoring, education, and program development for project management staff.  Ms. Hallman has a Bachelors of Science Degree in Computer Science and Mathematics from Edinboro University, a Masters Degree in Business from Penn State University, and a Masters Certification in Project Management from Villanova University.  She has worked in the information services arena initially in software development and later in project management.  She is PMP certified.

Selling Project Management

Written by Peter Taylor on . Posted in Articles. 3 Comments on Selling Project Management

‘Our customers really love us, so they don’t care if their projects are late and don’t work.’

Is this what you think? Is this what your project ‘customers’ are really saying?

How about this?

‘We figure it’s more profitable to have 50 percent overruns than to spend 15 percent on project management to prevent them.’

Do you ever get to hear that one?

Now I am not sure what sort of project world you exist in, but in my world, the commercial software world, there is often a challenge in getting customers of our products to accept the need to invest in project management from us as the product and services supplier.

Here are some ideas on how to address some of the common ‘pushbacks’ that you might receive in this situation:

 ‘I’m just buying the software and support from you; I don’t have a project…’

  • Your response – By investing in our technology, you are internally committed to deploying a solution and as such you need to consider the management of your investment in terms of scope, deadlines and budget

‘This is just a Pilot project…’

  • Your response – Pilot projects are a real showcase for the potential of performance management and will form the platform for future deployments. Therefore, a structured project approach is imperative in maximising this opportunity for your project team and your sponsor.

‘I’m very relaxed about project deadlines and budget…’

  • Your response – Someone in your organisation must be serious about this project and the associated (significant) investment. Therefore, the expected return on investment should be managed to deliver that ROI in a reasonable timeframe. This very statement is a project risk.

‘I have my own project manager and your project manager would not understand my business or project team anyway…’

  • Your response – Project Management requires a significant amount of domain expertise, I know. Our project managers are there to complement the skills and experience of your existing project manager. Even if we are part of a delivery team using SIs, Partners and your resources, we should have a project manager in place for effective planning and communication.

‘I can just use the support organisation for any issues I encounter…’

  • Your response – Yes you can, but this is a very ineffective way to deliver a project, there will be no coordination of resource requirements, promised timelines and scope can never be delivered against and your ROI will reduce as your own internal resources assimilate a new set of products.

And, perhaps the most common one?

‘Your project management is too expensive…’

  • Your response – What is the cost of failure for your project? What, therefore, is the value of de-risking that project by investing a relatively small number of days of project management?

I believe that a lot of the above also applies to ‘selling’ project management internally in organisations. Here are a few more perhaps typical comments that you might have come across:

‘Organizing to manage projects isn’t compatible with our culture, and the last thing we need around this place is change’

‘We aren’t smart enough to implement project management without stifling creativity and offending our technical geniuses’

‘We might have to understand our customers’ requirements and document a lot of stuff, and that is such a bother’ 

‘Project management requires integrity and courage, so they would have to pay me extra’

‘Our bosses won’t provide the support needed for project management; they want us to get better results through magic’

‘We’d have to apply project management blindly to all projects regardless of size and complexity, and that would be stupid’

Have you heard any of these? How have you managed to address them and ‘sell’ the value of project management?

People, if you look at the wisdom of sales methodology, generally ‘buy’ something for a number of reasons. Two of these are:

Fear

They are afraid that the consequences of not buying will be significant or they already have an issue that is causing them problems, or embarrassment, or concern. Sadly — and I have done this myself — when selling project management it is all too easy to reach for the latest project success report and declare that most projects fail, and not having a project manager in place is a major contributor to this failure. This is a negative and does not do much for project management (or the project manager). The tactic is to scare people into accepting project management and, whilst it can work, it will be a challenging task to prove the value of this forced decision.

Gain

Alternatively, people ‘buy’ something because they believe that they can gain something as a result, image enhancement, acceptance, better performance, reduced risk to them personally, etc. This is a far more positive approach and one that benefits project management, and if used successfully, brings project management to the point of a partnership with the buyer.

There is a lot to be done in the selling of project management, but to be clear, ‘Our customers really want to love us, but they do care if their projects are late and don’t work.’

Don’t forget to leave your comments below.

Peter Taylor is a dynamic and commercially astute professional who has achieved notable success in Project Management. His background is in project management across three major business areas over the last 26 years, MRP/ERP systems with various software houses and culminating in his current role with Infor, Business Intelligence (BI) with Cognos, and product lifecycle management (PLM) with Siemens. He has spent the last 7 years leading PMOs and developing project managers and is now focusing on project based services development with Infor. He is also an accomplished communicator and leader and is a professional speaker as well as the author of ‘The Lazy Project Manager’ (Infinite Ideas) and ‘Leading Successful PMOs’ (Gower) and ‘The Lazy Winner’ (Gower).