Questions? Feedback? powered by Olark live chat software

How would Steve Jobs have done a tool selection?

Have you ever conducted a vendor selection and given the winning prize to the vendor that had the most requirement features checked? And how about finding a year later that that the tool is not being used as expected? Did you not worry since you were able to show management that you did the right thing since you can demonstrate that the selected vendor tool does all of things in the features requirement list? No heads roll. No problem. This is a common story since many of us tend to get stuck with the features war syndrome. That is, go with the vendor that spent the most money building the most features. If all the features were dead on with our real purpose and objectives, then maybe we would be using the tool today and all would be happy. But, what if we find that our feature needs were a partial lie?

I propose that we focus  on the truth --- the real purpose of our business projects and the pains we want to diminish. Let's have a little fun and think about how Steve Jobs, one of my top heroes of my life, would handle this.

I would like to believe that he would have pulled together the right talented people that shared his vision and passion. Then he would have supported his people with the right enabling technology.

What would Steve say if I had asked him what he wanted as a list of requirements for a project and portfolio management (PPM) tool? I don't think he would have sat down and listed 107 features that the tool must have. I believe he would have have jotted down on a napkin his purpose and past pains, handed it to me, and then say go out and find a solution that solves these problems. Many of us tend to start with the opposite, which is identify a long laundry list of features. In fact, many of us would take that list and then pass it on to others to see what else they would add.

Let's take a look at how Steve would have kicked this off.

Steve Jobs' Napkin.

The following is my guess on what the napkin would have contained. (In reality, Steve would have probably said to not bother him with this, but I like to imagine the following story).

Purpose: Continue innovating with great design and capture new markets with products that can change people's lives.

Pains: 

  • Projects are not always aligned with or supporting our purpose described above.
  • Projects are not always effective, meaning the project's end customers are not always happy with the end results.
  • Projects are not always efficient, meaning they are late and cost too much, resulting again with unhappy customers.
  • They have too many issues and risks. Shall I repeat --- unhappy customers?
  • We haven't had the real-time transparency to make smart decisions fast.
  • Our way of doing projects are not innovative. We don't continuously improve.
  • People are not good at communicating.
  • People don't always know how to do the work the right way the first time.
  • It's all too complex. There's got to be a simple and elegant design to help our project people have fun.

You may agree with me that most PPM RFP features list wouldn't even cover half of the above. Or if it would, you really wouldn't know it. You may get lucky.

Mapping Steve's Napkin.

The next step in our story is to take Steve's napkin notes and move them to the next level. Let's choose the following objective from the napkin and add four objectives:

Projects are not always efficient, meaning they are late and cost too much, resulting again with unhappy customers.

  • Consistently have a set of steps and direction that drive better requirements gathering
  • Tips on how to better understand end customer's objectives
  • More transparent communications between the project team and the end customer
  • Better understanding of quality expectations and balancing it with speed to market

How can a PPM tool help? Here are a few examples taking it down to the next level:

  • Consistently have a set of steps and direction that drive better requirements gathering
    • Explain how your tool can contain a set standard or best practice action steps to be used on all like projects. Describe how these steps are created and then reused over and over?
    • Explain how they can contain the right knowledge to give people guidance and good practices.
    • Can your tool allow people to work together while designing these new process steps?
    • Show how fast project team members can get to this information.
    • Show how easy it is for the standard to get updated with lessons learned
    • Tips on how to better understand end customer's objectives
      • (same requirements as above, so we have this one covered)
      • More transparent communications between the project team and the end customer
        • Describe how your tool can assign different team members, stakeholders, and end-users to the project activities
        • How fast is it to assign people
        • End customers will not be trained in the entire PPM system, so explain how intuitive for them to quickly figure out their own assigned tasks
        • Does your tool have a messaging feature so team members, stakeholders, and end users communicate with each other from within the project
        • Explain how fast and intuitive it is for people to use the messaging features
        • Do the messaging features tie in with email notifications
        • Etc.

Help Vendors See the Bigger Picture.

A great way to prepare for a smart tool selection is to provide the right information to the vendors. The more they are informed, the better they can show if they will help you succeed. Don't just send them the lower level requirements items, but also include why you are asking these requirements. What may surprise you in a good way is some vendors may come back with a different spin on how to solve the higher level purpose and objectives. This different approach may be better than your initial thoughts. Most vendors know how their end customers use their tools to solve similar needs.

Keep in mind that there are other factors to consider besides the vendor features. For example, people, process, and culture impacts. Also executive commitment and support for fanatical end-user training. For example, if an objective is to get the most out of the new solution, then ask the vendor how they will provide the best deployment process to ensure adoption success rather than asking them how fast they can get the people trained.

Do you think Steve Jobs would have wanted to spend $200K on a new tool because of the tool's vast feature set, or do you think he would have preferred to spend that money to provide people a way to better innovate with great design and capture new markets?