Thinking ROI

As Project Managers we have the ability to help bring back focus in a tough economy. And that focus now, more than ever, should be on the customer and the ROI.

I got to thinking about this whilst reading Kendall and Rollins Advanced Project Portfolio Management and the PMO: Multiple ROI at Warp Speed on PMI’s ereads and reference: They write:

“When an organization faces insufficient market demand, the number of projects in the organization increases. All executives are pressured to find additional ways of meeting the goals. Therefore, the pressure on project managers and resources becomes greater. The result is predictable but not intuitive – the more projects that are initiated with insufficient resources, the few projects are finished and the longer each project takes to complete.”

Is this happening in your company? Are resources being stretched, accomplishments minimal, and stress levels high?  I’m starting to hear about this alot; companies are looking at fluctuating market conditions and sort of freaking out. They all have to ‘do something!’ Fast!

So they develop projects to ‘do something’ but these projects are done in a rush, out of fear for individual survival, and with minimal thought to what the customer wants, and what the return will be. This then results in too may people being stretched too far to do things that don’t actually improve sales anyway.

I’m also reading alot about ‘value’. Value is a concept used in lean manufacturing and I’m encouraged to see that PMI is starting to think about the use of lean principles in Project Management.

What exactly is value?

Value is something the customer is willing to pay for; anything else is waste

(Pyzdek and Keller, 2010, p.46)

Let’s think of value to the customer as a bar that we are trying to reach. The customer has a vision for what they need from a product or service; what they are willing to pay for. This is their envisioned value. And it exists whether we have tapped into it or not.


Let’s assume that we have some idea of the envisioned value and are creating something to get to that, so that we can pull out the return from that value. Everything prior to that bar, all the efforts we make in projects is value that has yet to be realized, is unrealized value (KPMG, 2009). Unrealized value includes the investment in resources, time, materials made to reach the bar.

When you successfully complete the project, you then ‘realize’ the value, customers are buying and you start to see the return on the investment (ROI).

This is really simple, and it probably makes sense to you.

Startups get this.  In fact, the startup culture is all about what the customer wants.  In my company (a startup) everything is customer driven; almost all  projects are for customers, and almost all resources are involved in a project that adds value for customers. Maybe that’s why startups are the new engine of the economy.

So what does all this have to do with Project Management? Project Managers can help companies keep their eyes on the prize. We monitor and control the scope, we serve to integrate all the pieces, we know the whole shebang. So we are in a unique position to question the course and suggest adjustments to get back on track. When we marry that up with an ROI focus, we then speak the language of business, we then talk about what senior executives care about, which increases our own personal value, but more importantly, makes a positive contribution to increasing the bottom line.

In other words, we can help prevent lots of wasted investment and effort by evaluating the intent and scope of our projects in the light of a few key important points.

Point 1:

Projects should be initiated because they somehow add value to what is sold to the customer.

Point 2:

We should absolutely seek out what the customer values, and make it central to any project.

Point 3:

The Return on Investment (ROI) is the point. Until the project completes successfully, everything done on the project is unrealized value and wasted investment.

Getting it Done – a PMP’s Value Add in Startup Territory

So I’ve been working in New York Silicon Alley Startup Culture (initial caps intended) since April.

I may have mentioned somewhere in this blog that on some days it’s like being on swift, sleek, schooner – wind swept sunny goodness, white cotton shirt flapping in the breeze.

And on other days…it’s Deadliest Catch choppy, fending through 10 foot high cold icy waves of rapidly approaching deadlines.

Or – somewheres in between. And mostly, a lot of fun.

I’ve had a few good a-ha moments I wanted to share with you.

First A-ha: A PMP’s value-add is in Implementation

There’s one very important thing I’m learning about startups and it makes me think about thetalk I went to with Eric Reis where he noted that the hardest part about growing any company is the boring second act, where company growth means dealing with the tedious, non-sexy stuff. Stuff like documenting repeatable processes, taking down meeting notes, deciding on follow through – all things very brilliant entrepreneurs don’t really want to deal with.

Like getting it done? There's a startup looking for you!

So I have to give credit to my company, Crowd Fusion, for having the foresight to hire someone like me – an extremely process orientated ‘Now Wait A Minute That’s Not What We Decided Yesterday’ type of girl.

Seriously, I think that every growing startup needs someone to implement decisions. Implementation (aka execution) is having a plan for making brilliant ideas come to life.  I’ve found that includes:

  • Recapping decisions at the end of meetings
  • Figuring out what next steps are
  • Not letting people leave important decisions without figuring out who is responsible for what (action items)
  • Simply reminding people of action items and gently prodding until they get done

This seems like normal PM stuff – but really, I’ve heard form my co-workers that other startups they’ve worked for are lacking this skill set.  And then those companies hit walls as they grow.

As a PMP, I’m starting to see that my value-add in a startup is not in the Initiation and Planning part of IPECC, because startups are havens of good ideas, and brilliant minds who know how to…well.. “startup” stuff.

My value-add is clearly in pure decision Execution. If you are thinking of joining a startup and you’ve worked in big corporate firms, you can provide tremendous value just by knowing how to get and keep the trains running.

Second A-Ha: Don’t Control the Process, Control how the Process is Built

One of the most key Agile and Kanban principles is that teams of people are the best originators of processes, not corporate policy offices, or centralized PMOs. Process has to come from the team who is going to follow the process.

So how do you do that? You do that by setting up a process for process change that incorporates the following:

  • Spontaneous Creation of Process  Anyone at anytime can create/modify a process
  • Easy Documentation  The process must be documented following an easy to use template that specifies actors, inputs/outputs and step by step details
  • Peer review and approval   New/updated processes must go through peer review. This ensures the all important buy-in factor
  • Process Management Review and Approval   New/updated process must go through process management review. This ensures that integration points will be addressed, especially if the new process impacts other existing processes.

Let the Team Figure it Out

Here’s the deal, I don’t control what’s in the process, i.e: the content. I’m available to teams if they want some help, but generally, process review doesn’t come until the team has already decided on what they want. The process belongs to the team.

So by providing the mechanism for process change, rather than detailed control of the content, we can still allow teams to innovate and grow with what works for them, but get good, ratified, documented process as well. It’s the best of both worlds.

What’s Really Bothering You? Ask Why Five Times.

Why, Why, Why, Why, Why

I’d like to share with you just a a few of the fresh ideas and new ways of thinking shared by Eric Ries at a LeanDC talk at American University last night.

For those who’ve never heard of Eric Ries, he is the visible speaker for the lean startup movement. You can read more at TheLeanStartup.com but briefly, the lean startup movement is about a huge paradigm shift in our ideas about management.

We are still using legacy ideas about entrepreneurship so the failure rate is embarrassing
Eric Ries

Evidently, lots of people agree with him; lean startup incubators are popping up across the country, and universities like Harvard are creating lean startup courses, all around the ideas Eric Ries uses and describes in his blog, Startup Lessons Learned. (he hasn’t even put out a book yet – that’s coming).

Master the Details in the Bone-Crushingly boring Act Two

There comes a time in the life of every startup when what you’re doing is no longer sexy.

Eric compared this period to the company story montage that happens in movies about businesses. Act One is always the setup, the good and the bad about the protaganist, that comes into play when they face a great challenge.

Act Two is always a photo montage of the protaganist setting up the business, maybe moving in, happy shots with customers, getting bigger, hiring people and eventually ends with the protaganist on the cover of a major magazine cover. This part always takes about two minutes in the movie and it’s usually setup for some major challenge in Act Three.

Eric says that the most important act for any company is Act Two – the no-longer-sexy middle part when all the fun and games are over and the ‘bone-crushingly boring’ stuff like product development meetings, and learning how to prioritize occurs.

In Act Two you’ve got to figure out how to constantly create value and eliminate waste, you’re still making those important strategy ‘pivots’ that may send you in a brand new direction entirely, you’re figuring out how to support your existing early adopter customers, while at the same time position yourself for new products. And all of that is the boring stuff, and the hard stuff.

I asked Eric this question: What was the hardest thing and/or most boring change that had to be put in place in Act Two to get to Act Three?

And he responded: “The Five Whys”.

“The Five Whys” is a lean manufacturing technique where you ask simply, why something occurred – but you must ask five times. I guess there is some magic in the number five, but evidently, when you keep asking why, you get to the root cause of the problem and deal with that, rather than wasting time and energy on a solution that doesn’t address the problem.

In a manufacturing environment, you can’t stop and revisit your process for three months. You have to keep moving. So he says that at his company, every time there’s a mistake, there is an immediate post-mortem; a simple, short meeting where the root cause is identified through five whys analysis.

Why, Why, Why, Why, Why

Here’s a common five why example

  • I gained five pounds over the holidays (problem)
  1. Why? – That damn rum cake.
  2. Why? – After that my sweet tooth kicked in and I wanted more sweets.
  3. Why? -I’ve been dieting for so long that I’d been deprived.
  4. Why? – My diet doesn’t allow sweets for rapid weight loss.
  5. Why? – (But I gained), maybe my diet doesn’t work for me (root cause)
  • I will find a diet that allows me to lose weight and also have sweets, so I won’t over do it (conclusion).

Wikipedia has a great, simple intro to the Five Whys and I encourage you to read it. Here’s an excerpt:

“ The real key is to encourage the trouble-shooter to avoid assumptions and logic traps and instead to trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. Note that… the fifth why suggests a broken process or an alterable behavior, which is typical of reaching the root-cause level.

“It’s interesting to note that the last answer points to a process. This is actually one of the most important aspects in the 5 Why approach…the real root cause should point toward a process”

If you follow five whys, the system will teach you where you need to make adjustments.

My key takeaway is that it’s that incremental benefit of boring but constant investigation, that supports the engine of success.

A Wild Ride – headed into Startup Land

It’s been like two whole months since I posted.

It's a wild ride

That’s like Deadsville in SEO land.

Well…let’s sort of think of it as a resurrection.

Here’s the big news..I’ve left public sector contracting, and I’m working for a startup.

And it’s different.

Startups are like new frontier;  the product is growing, expanding, and the processes are revealing themselves, then evolving.  Everything is change, and that seems to be the constant.

Some Early  Lessons

I’d like to share with you two things I’ve already learned in the short time I’ve been in this new world.

Process Is respected because interaction is key to agility 

I have never worked in a place that respects process so much. Really. Seems like that doesn’t make sense- small company, respect for process, how can that be?  Here’s the deal – the leadership knows that bottlenecks thrive in the lack of clear communication of the rules of engagement.

They understand this saying that I borrow from Donatella Meadows’ book Thinking in Systems.

You think that because you understand “one”, that you must therefore understand “two”, because one and one make two. But you forget that you must also understand “and.”

It’s like playing a baseball game.  The rules don’t get in the way of play, but without the rules, there is no play.  Interaction is the key – we focus there, we clarify that space.   Then we document it and get moving.

Honest dialogue has an exponential effect on the time to process adoption

So in some companies there are layers and layers to decisions.  You know that what you communicate in one meeting will be re-hashed by others in other meetings.  So instead of being clear and honest, you think about how your boss’s boss will get your message.  Which means that you probably hold back what you really want to say.

The layers of hierarchy are a drag on the time to decision (i’m sure there’s a formula out there somewhere).

But this place is different.  Painful even.  Because, see, when you think you have a great idea and someone gives you their honest opinion, it can hurt.  But that short term pain is worth it, because it exponentially reduces the time to production for process.  It’s like – tell the truth, decide what were gonna do, document it, and….go.

Letting Go of the Old Persona

So, two things that I personally had to shift.  First, usually, as the PM, I’ve been the one sort of ‘instituting’ process.  You know, setting up the risk management plan, and change control boards and all that jazz.  But when a whole organization respects process, that means in essence, I’m not the only process expert in the joint.   I’ve had to go in as the facilitator, the communicator, the person who observes and elaborates, and acts a s SME for best practices.    I’m not the only know-it-all in the room.
Second, adapt, adapt, adapt.  Some processes will change weekly.  Gone are the days of posting a big Software Lifecycle Plan on the contracting officers’s wall and saying ‘ Here is our process – May it live in peace and harmony for the life of our contract.’  Nay…I’ve had to let going feelin’ inordinately proud, and embrace adaptation.  It goes like this: it was great last week – but now that we’ve figured it out, it’s becoming clearer, and we’ve now realized that there’s this other piece that needs to get put in, or that there’s this other piece that’s a bottleneck and needs to be pulled out.  Process, then, becomes alive.  People, then, get into the habit of checking the process.  A culture develops that respects process, and therefore, paradoxically, is not slowed down by process.

It’s a very cool ride.

The Uncertainty Principle OR How to Choose the Right Methodology

I ran into a old PM buddy in the frozen aisle of Trader Joe’s the other day. “Are you Still doing Agile?” slipped from lips before I could stop myself (it’s sort of ‘Gosh Michiko – can’t you turn it off at Trader Joe’s on Saturday?’ Sigh).

Which One Do I Choose???

Anyway, my friend was gracious,and it turned into a why-we-have-abandoned-Agile discussion. His company, mind you, was one of the very early Agile adopters and is the place I learned and came to love Scrum. A huge, established, reputable and very solid financial institution, it was perhaps a little bold of them to try.

Nonetheless, he explained, Agile just didn’t fit. And they gave it a good go too – with dedicated Scrum rooms, co-located developers, lots of whiteboard space..the works.

I’m still scratching my head, and the blogsphere is hot with choosing-the-right-software-development issue posts. Sometimes its friendly how-to articles, like Project Smart’s recent post on Waterfall vs. Agile and sometimes it’s out and out Waterfall vs. Agile wars; like the Integrated Master Schedule showdowns between Herding Cats and Critical Path. May the best blogger win.

But I like what the newest methodology contender has figured out. Lean Startup is way out there – they think Agile is slow. But Lean Startup leader Eric Ries based his method on the degree to which a problem and solution is known or unknown. He asks to what degree the solution is known and to what degree the problem is known. The problem question is: ‘what is the problem we’re trying to solve?’ The solution question is: ‘do we know what we need to do to solve the problem?’ I think he’s on to something, because the question about degree of uncertainty is reflected in the organizational culture of a company.

So I started mentally evaluating companies I’d worked for in light of these two questions. And I found that where the problem is known and the solution is known, the company is less likely to take on rapid development software methods. Whereas, where the problem is unknown and the solution is unknown, the company culture tends to welcome and keep using rapid software development methods.

For example, the large financial institution. The problem is ‘how can we grow money for our clients?’. That’s a pretty stable problem and is well known and built into the company’s value statements. In other words, if you’re at that company, you know the problem, there’s no way you don’t. And the solution is well formed; ‘work the market’. So all software projects at the company are approached from this angle. Agile didn’t take off there, but incremental waterfall works well.

A smaller software company I worked for; the problem was ‘how can we build our expertise into a software product to satisfy the needs of unique niche?’. The solution was well defined; ‘customize a COTS solution’. That company also uses an elaborated incremental waterfall approach. Surprisingly, given their small size, I thought Agile would take off there too, but it didn’t.

Another large financial institution; the problem was ‘how can we reduce our financial risk in a shaky mortgage market?’. The solution was unknown. And in this very large, well established institution, Agile projects do quite well.

I used to think it was the size of the organization and or the organizational aversion to change that determined the software method. But now I think it’s the extent to which the problem and the solution are either known or unknown; ie the degree of uncertainty.

The Lean Startup idea is that both the problem and the solution are unknown. So the point is ‘continuous development’ with a ‘minimally viable product’ so that the team can ‘fail fast’ and and move both the problem and the solution from the realm of the unknown to the realm of the known. I wonder if and when this happens, Lean Startup will have to go more Agile. That’s another discussion.

Kanban developed to maximize the production of a known solution. Developed from the automobile factory floor, the solution was well known; ‘we are building cars’. But the problem was unknown from year to year; ‘what kind of car is the best this year?’. In this situation, where the solution was well defined and stable, but the problem could change, Kanban developed; which controls the build speed of solutions, regardless of how that build changes over time.

It’s starting to feel a little like this:

Known Problem/ Known Solution – Use Iterative/Waterfall
Known Problem/ Unknown Solution – Use Agile
Unknown Problem/ Known Solution – Use Kanban
Unknown Problem/Unknown Solution –  Use Lean Startup

I’ll keep using these two questions as I try to figure out what works best where. But I think what’s really becoming quite clear is that there is no one way, anymore. And it’s not just an Agile vs. Waterfall world either. We’ve got to start developing new tools to help PMs make quick assessments and get on track to successful implementations.