Project Management

PMO Building Block 3: Which Tools Make a Difference?

From the I wish I had me when I was you... Blog
by
"I wish I had me when I was you..." That expresses precisely how I feel each time a project manager or PMO leader tells me a story about their frustrations encountered while trying to create effective and sustainable change, build (or fix) a PMO, or deliver projects successfully. I always think to myself…I wish I knew then what I know now. I’ve made it my mission to share with you everything that I have learned while creating change and building PMOs in both large and small organizations for the last 24 years, many of those years as an employee in the "hot seat" responsible for building internal capability. I’m hoping these articles help you along your journey as you continue to evolve and develop skills and techniques to be the high-IMPACT leader you are meant to be. Learn more at ImpactbyLaura.com

About this Blog

RSS

Recent Posts

Becoming a Customer-Centric PMO

10 Steps to Ensure Project Rescue Success

Things to Stop Doing to Be High-IMPACT

The Big Credibility Differentiator

Did You Know That Project Management Can Change The World?

Categories

PMO

Date

linkedin twitter facebook Request to reuse this  


Do Some Tools Have a Proven Success Over Others?


The bottom line on tools is this…if you aren’t using it as it was designed and/or have chosen to customize it so that it barely looks like what you started with, you are slowly going to degrade the functionality and usefulness of this tool to the point that it will lose the ability to give you good quality information you can rely on.  All of the major tools companies out there claim to solve many of the basic project management objectives, but for the more advanced users, one tool isn’t going to be perfect for you no matter how much you customize.

Unfortunately, I’ve seen what can happen when companies look to make the tool fit their process instead of considering that the other way around might actually be more effective.  This doesn’t apply just to project/portfolio management software, as many of you realize.  People will take that bright and shiny tool out of the box and transform it into something that they swear they needed in order to get any value from the tool.  Then, years go by, and you’ve put so many customizations on top of the tool that it is barely recognizable as that off the shelf product you purchased many years prior.  The vendor will be telling you that you can get so many of those customized features in their newer version of the software.  You are finding that you need to put fix on top of fix to get the software to work the way you had hoped three changes ago.  The executives in your organization don’t see the real business value in the tool (where are their fancy dashboards with reliable data?), so you are having a hard time convincing them to invest another hefty sum of money in upgrading or replacing the tool.  Any of this sound familiar?

Assuming you can convince leadership to invest in replacing the tool or for those of you that are making the investment for the first time, below are some recommendations for getting it right.

Your best bet is to start with the best future in mind, not your current state.  What is it that you are hoping to produce as an ultimate outcome of using this tool?  Is your focus resource management?  Is it cost management?  Is it fancy dashboards that the executives can use?  Figure out what matters to you, as the owner of the tool, and also to your stakeholders.  It is in your best interest to take the time to figure out what each of your stakeholder groups needs in order to feel a part of the process and to make sure that they are getting real, tangible value from the tool.  Otherwise, you will have a disaster on your hands when you implement something (customized or not) that doesn’t meet stakeholder needs. No one will use it, or if forced, they will find the path of least resistance, which equals least amount of valuable information.

In addition to gathering requirements from stakeholders (Software Development 101, right?), you also need to take the clean sheet of paper perspective for your processes.  Put aside what your tools or processes do for you today and think about what you ultimately want to deliver.  Once you’ve done that, you may realize that your current business processes don’t actually fit where you are headed with your new set of requirements.  That’s OK.  Change can be your friend here.  You can either scrap all of your old processes in favor of your new ones or take advantage of this opportunity to align new business requirements with some of the lean and six sigma strategies for process improvement applied to your existing processes.  Either way, you are still only looking at requirements and the processes.  The tool doesn’t yet come into the picture.  There is a reason for this.  If you engage with vendors before you’ve done your homework, you will have them all “helping” you define your business processes in a way that suits their tool, specifically.

Now, I’m not suggesting that you need to get into very specific details of your processes before tool selection, but you need to know what you want.  Figure that out and then you can be clear with vendors about what you want when you engage with them.  The more you know about what you want as an outcome, the more the vendor can help you achieve success.  The vendor will be able to tell you how to best achieve your desired outcomes with the tool they are pitching and they will be able to make some best practice recommendations to your processes to get to the most efficient results.   That’s a very different role than having them define all of your processes for you, some of which will only be there because that’s how their tool works instead of what you actually need to run your function.

Upon reaching agreement on the business requirements and business process, it’s time to start looking at your tool options.  Vendors will fall all over themselves to help you with your project management software needs.  There are the primary companies that create the software and then there are third party implementers that will implement the software of your choosing.  Your best bet is to do your research here and look at what other companies of your size are using.  This is easy enough.  Google searches and actual conversations with people will get you everything you need.  There will be many war stories from companies that have implemented the software packages or web based/Saas model tools.  Some will be great, but more will not be so great.  Some people will claim that a certain tool is amazing and others will say that that same tool is horrible.  Neither of them is right and both of them are right.  It’s all about the experience that they had in implementing and using the tool in their organization, how much they customized the tool, and what they were looking for as outcomes.  My experience has been that those that didn’t follow the suggestions in this article will have the worst experiences to share with you.

There is one very important consideration with all of this and that is that you must keep the people engaged in the process of defining the requirements and get real agreement to engage in the use of the tool once it is implemented.  The primary reason that a project management tool is put into place is to help in managing and leveraging the project data to make decisions.  Those reports that you and your executives want will only be as good as the data put into the tool by the project resources.  Bad data in equals bad data out.  Do not underestimate the time and effort required to educate, train, and build structure around the users of this tool and how they interact with this tool.  This user management process will be an ongoing communication and training effort that must be planned for when considering implementing project management software.

One final note…

No tool will be perfect.  Pick the one that most closely aligns with your already defined objectives and key business processes.  My advice…use the 80/20 Rule.  Expect the tool to meet 80% of your needs through no customization (even if this means modifying your processes to meet the tool instead of the other way around) and then look to make modest customizations or find mechanisms outside of the tool to meet your last 20%.  Any more than that and you will be paying for it for years to come!


Posted on: March 06, 2017 12:53 PM | Permalink

Comments (2)

Please login or join to subscribe to this item
avatar
Drew Craig Sr. Agile & Product Coach| Vanguard Philadelphia, Pa, United States
Great stuff, and so true. I almost thought I was listening to a recording of myself :)

Thanks Laura.



avatar
Renee Robinson PMO Director| C2G Orlando, FL, United States
Great article Laura, and well thought out. As we continuously evolve as organizations our tools need to evolve too, but we also must review the usefulness of the information and customization. Does it have the same relevance that it did previously, etc. The 80/20 rule is a good suggestion for a measuring stick.

Please Login/Register to leave a comment.

ADVERTISEMENTS

"The scientific theory I like best is that the rings of Saturn are composed entirely of lost airline luggage."

- Mark Russell

ADVERTISEMENT

Sponsors