Prioritizing from the Get-go

As you may know, I believe many corporate resourcing & delivery issues stem from not properly prioritizing customers & projects. You can read my recommendations on how to approach those in my prior blog post. Today, I’d like to take a step back and look at prioritization from the onset of customer project introduction. In government contracting, this is called the gate review process.

A business faces immense pressure to succeed these days, facing obstacles from all directions. This might be driven from competition, or budget reductions and uncertainty, investor return or simple from cash flow concerns. Amidst all this chaos, the only real thing the business can control is how they behave. It is up to the business to pursue the business, then accept the business and support the business. Ideally all parts of the business are in sync about the choices being made. Unfortunately, that is not always the case. In my experience, most businesses pursue any prospect of business with a vigor and stubbornness, minimizing any negative feedback or concern. Many times this is done by simply not including other parts of the organization in the sales process.

These challenges can be overcome by simply asking the right questions (and following through with the outcome regardless of the answer) throughout the process. This process does not need to be too tedious. However, it should be thorough enough to have all pre and post involved departments participate in the conversation, being able to have their concerns heard, acknowledged and if possible, mitigated. Three simple questions you can ask during this process are: Can we do it?, Can we win it? and Can we make money?

Can we do it?

Fundamentally this is the first step. This step is really about reviewing your capabilities as and organization and determining whether you can deliver. Some ancillary questions include:

  • Do you have the resources? Can you get them in time?
  • Do you have the applicable skills?
  • Have you done this before?
  • Can you identify and mitigate the risks?

Can we win it?

This step is determining how you stack up to your competitors. It is also about doing an honest assessment of the work involved to ensure you can price within the required range to win it. Questions to consider include:

  • What is your existing relationship with the customer?
  • How do you stack up against the competition?

Can we make money?

While there may be reasons to pursue opportunities with limited margin, the answers to this questions should be most honest. Businesses exist to make money. Continuing to pursue opportunities where the prospect of doing so is limited puts the whole business in jeopardy. This discussion will put some key business assumptions to test about efficiencies, repeatable processes, or the reality of custom work. Questions to consider include:

  • What is the customer’s budget?
  • What is the contract type? Where does the risk lie?
  • Where do your competitors end up with price?
  • Can you mitigate the financial risk?
  • Are their efficiencies you can gain?

It is at the intersection of “yes” to all three of these questions where the optimal place exists for your business to pursue new customers or projects.  It becomes a slippery slope when only two questions result in “yes.” You may strategically choose to pursue business when you have two out of three, but these come with very severe risks. Wasted resources and degradation in customer success are two potential outcomes.

Prioritization is critical to business success. Having checkpoints at multiple stages throughout the sales & pipeline, customer success and PMO processes significantly improve your ability to work on the right projects for your customers. It also helps your ability to delivery and make money from your initiatives.

I want to thank David Stearman for his presentation on Gate Review Decision Making at the Association of Proposal Management Professionals-National Capital Area (APMP-NCA) Mid-Atlantic Conference last week. This blog post is a compilation of my notes and thoughts regarding project discovery & decision to move forward.

Be a resource, not a commodity!

I had the chance to see David Belden (founder of ExecuVision International) deliver his keynote at yesterday’s Association of Proposal Management Professionals-National Capital Area (APMP-NCA) Mid-Atlantic Conference. The topic of the keynote was “Relieving Anxiety in the Procurement Landscape.” At face value this didn’t sound particularly interesting, but just a few short minutes into the presentation I found myself taking my notebook out to starting taking notes. The key take away for me had less to do with anxiety and more about positioning ourselves to be resources, or risk being reduced to commodity status.

We all know that selling on price is not the ideal position. We also know that the pace of business has significantly increased. Unfortunately, only these two things matter when you are a commodity. I think we also know, at least conceptually, that adding value to your customers is how you differentiate yourself. Often we attempt to add value by sharing our methods and solutions for free. While these points are not new concepts, Mr. Belden really drove home the idea that every product or service is on the path to commoditization. He further concluded that our inherent reaction to differentiate ourselves results in becoming the commodity we feared we would become. Customers begin to know, or think they know, enough to comparison shop your solution. These are sobering thoughts as we work to grow our consulting company.

As for the preventative strategy, Mr. Belden challenged us to listen closely to our clients and prospects, with special attention paid towards their anxiety. Embracing your client’s anxiety allows you to become a valuable resource to them and can open up other areas of opportunity for you.

The Importance of Understanding Why

Last week my 16 year old daughter took her PSATs. While we were talking to her about how she thought she did, it became very evident that she had no idea why the PSAT was important. She claimed that nobody had told her. We discussed a couple of questions she didn’t know and whether she guessed or skipped them. We asked if she knew which option was the best choice for the PSAT. She didn’t know.

This entire conversation frustrated me quite a bit, as I attended a session with her in the Spring about planning for college and some of the major milestones, including the PSATs. Additionally, for most of the summer I was reminding her that she had access to SAT practice tests and she should make the time to take them as her time becomes limited once school starts. At one point in the conversation, I realized she was right. Nobody had explicitly sat down and said the PSAT was important for x, y and z reasons. The importance was implied within broader conversations, but never explicitly stated.

It was easy for me to extrapolate this problem to project management as there have definitely been in situations where you were challenged with a request for less than solid reasoning, mostly because the other person didn’t understand why you were asking. We see this all the time in features and functionality delivered to spec, but that never at all meet the needs of the requestor. To the person doing the explaining, their why is fully ingrained in their own experiences. Each time he/she does this specific process, they have to execute these workarounds because the business need has outpaced the software development. The software developer sees the requirement for the new feature, and implements his interpretation of it. Unfortunately, the lack of understanding of the business needs and processes often result in a working feature that doesn’t fully resolve the business need (although it might replace the workaround).

Flexible development methodologies that allow for knowledge sharing, iterative review and feedback loops are helpful in minimizing this type of issue. As project managers and analysts, we need to hone our ability to ask “why?” not just “what?” Our documents and artifacts need to be flexible enough to articulate both, otherwise there’s a lot to be lost in translation.

Do you suffer from “fear of making mistakes”?

We often talk about “fear of missing out”, but I’ve found that “fear of making mistakes” is a much bigger issue in the workplace. I’ve worked with project teams where this fear of making mistakes resulted in in lack of communication and frustration on all sides. If we are not willing to make mistakes, how then do we learn and grow? How will we solve the complex problems?

Fear of making mistakes has significant impact to communication among team members. Those resources that are afraid to make mistakes tend to be less forthcoming with details and information. If only positive or complete information is shared, project management and team dynamics become very strained. As the project manager, I want to hear all of it. Help me understand the true status – what’s working, what isn’t, what the next steps are and how you anticipate the changes to the schedule. I’m not there as a passive participant. I am part of the project team, one that team members can rely on to help minimize issues, remove obstacles and ultimately celebrate success. I can’t do that effectively when members only share limited information.

Unfortunately this problem gets more complicated as time goes on. The resource is afraid of making a mistake, so withholds information. This leads to frustration on behalf of the project manager, who may be required to escalate. This makes the resource more nervous, so even less willing to share the low points. Without the proper communication, timeframes, effort and quality of work all come into play.

The onus of identifying this problem and mitigating the circumstances falls to the project manager. The project manager may need to set of separate touchpoints with the specific resource, and review the individual tasks. Targeted questions on next steps, and precise estimates will need to tracked very regularly. Additionally, feedback, especially on areas that aren’t working or need improvement, will need to be clearly documented. All this needs to be handled delicately as I found the resources who experience fear of making mistakes are usually working really hard. The lack of communication makes it difficult for the project team to see the results.