on pies

I recently presented PIEmatrix at the CBP Summit 2008 in Scottsdale, AZ. The conference is one of the top PMO (Project Management Office) events in the US. Most attendees where PMO directors from large enterprises. We had the opportunity to conduct a conference survey for all the attendees. The survey asked “what are the top 3 best practice needs for project implementation that you would like to discuss with your peers?”. We received about a 90% response rate. The result displayed 34 different process standard needs. The following are the top five:

1. Resource Management - 17%
2. Risk Management - 8%
3. Portfolio Management - 8%
4. Project Management - 6%
5. Financial Management - 6%

This is an interesting statement showing where the pain is in the project industry from the PMO perspective. I would assume that resource management is also the top challenge project managers face since their issues funnel up to the PMO and upper management. This was not unexpected since many of our beta customers have asked PIEmatrix for more resource management features. However, it’s great to be able to show real metrics from the market.

Further in the conference we learned that within resource management, the challenges include utilization management, motivation, skills mapping, etc. One breakout workshop came up with some shared best practice needs and example solutions. At the conference we captured this data in our new PIEmatrix crowdsource-community platform. This opens up the ability for the PMO directors to go back to their offices and continue to discuss and share best practices with their peers. This is still a work in progress, but the need in the market to collaborate on resource management pains is very clear.

Ever since Web 2.0 products like Flickr, Twitter, etc. and new design approaches from Apple shook up the market, there has been a lot of buzz around the user experience. Notice I didn’t say “UI design” since too many people correlate that with “flashy and colorful, yet missing intuitiveness and functionality”. User experience is really much more broad. One recent trend was well noted by Alex Iskold in his blog the rise of contextual user interfaces . And today, Mr. Iskold wrote more about how the user experience is King . What is interesting is how he categorized user experience as providing “value” with components like useful, desirable, accessible, credible, findable, and usable. He further makes a good point that if providers ignore these points, their competitors may not.

Flickr, Twitter, Digg and others have redefining user interface standards with contextual design. So instead of seeing a page crowded with buttons, menus, fields, etc., the page is more simple and clean and delivers the menu or field choices based on user actions, only when needed. How else can these Web 2.0 solutions command millions of users overnight? Who reads training guides anymore? Not the younger generation, who have been moving into the workforce.

That brings me to the enterprise market. Lately, there’s been buzz around Enterprise 2.0. The Enterprise 2.0 Conference in Boston this year drew a large crowd. Check out their definition of Enterprise 2.0. When speaking with large organizations, I have found that most of the focus has been around leveraging wikis, forums, company blogs, etc. What about the user experience? It’s easy to make the argument that it’s more about delivering functionality than that deliver business value. I think this is good, but isn’t that what all vendors have been claiming to provide over the past decades? Why are many enterprise applications either collecting dust, getting shut down, or taking months or years to integrate with end users before it becomes seamless. Imagine if early Flickr users said hey, I really like the idea of sharing my photos, but trying to make it work sucks. Would there be millions of users today? Not likely. Large corporations have spent millions of dollars on feature heavy solutions and three times that on installation, customization, and user training. Wow! What a market for startups who can provide a me-too option with a much smarter user experience. Remember that Mr. Iskold included “usable” and “useful” not “everything under the sun”.  Imagine an executive saying, let’s not only spend millions, but let’s improve ROI with increased user adoption.

My hat is off to 37signals for being one of the first in the Web 2.0 space to tackle team collaboration for small businesses. They did this with holding off on all the bells and whistles, focusing more on what’s important, and providing a sweet user experience. At PIEmatrix, our vision is the same for the enterprise market.

If you’re an enterprise looking for new software, consider the user experience as you would expect from Facebook or LinkedIn. Instead of spending weeks with a small team managing the list of RFP vendor requirements, cut your time in half and give the other half to your front-line users. Let them vote on user experience and give that a 50% weighted scale. If you’re a software vendor targeting the enterprise, note the bar is raising. The guy across the street (in his basement) may find a way to your prospects’ hearts more quickly then you will.

(I like this topic so much that I created a category called “user experience” and will write more in the future.)

Do you need to build best practices for your projects? Maybe you can spit it out in one sitting. Maybe not. I recently wrote about using crowdsourcing to help build best practices for projects. The concept is working with your peers from different organizations, across industries. The power of leveraging others’ experiences is a win. Today, I want to focus on outsourcing to your own internal team. They deal with your process every day, so why not leverage their expertise?

One approach is to get the group together for a story-boarding session. Post-Its on a wall works. Or you could use PIEmatrix to help story-board. Focus on high level process steps first and keep it simple. Ask them to kick start by listing the deliverables. This is the easy part and you may already have this documented. Next is to list all possible failure points (future fires). Most everyone is a critic. So, leverage this. It may not take long to list experience with risk in each project stage. Now, turn the table and ask them to come up with high-level process steps to reduce the risks. This is harder, but at least they have a good starting point. At the end of the session, ask for volunteers to take certain process points to decompose into more detail. You will find the details goes to those who have the depth.

The other option is for you or your firm’s process expert to define the high-level process steps and then outsource the detailed definitions to the front-line team members based on their expertise.

Once you have your new best practice process defined (documented or placed in PIEmatrix) the challenge is to get it to stick. However, you have an advantage. The team who needs to do the sticking has personal stake. They are more likely to better adopt to process change if they helped build it. Over the longer term, keep the best practices fresh with process evoluton workshops.

Writing best practice or process content from scratch can sometimes feel like writing a book. You have that blank page starring back at you, waiting, waiting. Oh, can’t start now, gotta deal with this new fire. I’ll get back to it later. As mentioned in my previous blog, fires can easily keep you from figuring out how to avoid them in the first place. At some point (hopefully), you will find time so here are some ideas.

First, try to find best practice content already defined. Think of it as chunks stored here or documented there. Working with existing deliverables is a great start. Let’s say your whole process contains a dozen or so standard deliverable files. Open up the first file and review its parts. Each of these deliverable components can be turned into a process step. For example, a charter document could have a scope section. Let’s turn this into a process. Ask yourself — what’s the high-level stage for implementing this deliverable? Planning. What’s the mid level process? Define Charter. What’s the process step? Identify project scope. Now, you know where it belongs in the process schema.

Next is to write the details of the step. Ask yourself what is the best way to identify the project scope. This is the “gold” of your best practice. Start with a simple sentence. You can add more later. Then ask what role is responsible for this step (i.e., project manager, business owner). You may expand that step or add steps to cover each role’s responsibility. Finally, your step will then refer to the physical file (charter.doc) and where to find it. There you have it, from high level to detail level, covering process, people, and deliverables. You can easily do the same with the other charter document components and then move on to your other deliverable files. I call this “reverse process decomposition” since you are starting with the end result. Once you get the process covering your major deliverable documents, you can use it as is as a “quick win”. Over time, you can expand on your methodology as easily as a writer would add an extra paragraph in his or her novel.

The term “crowdsource” is defined by Wikipedia as a new word “for the act of taking a task traditionally performed by an employee or contractor, and oursourcing it to an undefined, generally large group of people, in the form of an open call.” I sometimes relate the concept of Wikipedia itself as a crowdsource model since an encyclopedia item is open for the community to elaborate, correct, or update rather than locking it down to one “expert”.

Traditionally, best practices or process methodologies have been devised by an individual or as small, closed group of experts. Often processes are generated within an organization from past experiences or collected from an industry standard, such as PMI for project management. I have found that one major challenge organizations have with defining or improving their internal best practices is the lack of time or priority commitment. They all know its valuable for the long-term, but most have fire’s they need to put out. I was recently at Charles Schwab in San Francisco, and process leader gave me a great analogy. She said its like a river flowing past you and and you see a person thrashing in the river, nearly drowning. You jump in and pull him out to safety. The next person comes by and you pull her out at the last minute. You’re exhausted, but there are more and more people thrashing for their lives and you jump in again and again to save them. While this is going on, you miss the main issue. Up the stream there’s a man on bridge pushing people off!

Many would like to build a better process (such as having people cross a different bridge), but are too busy saving the day. Coming up with a better method can take a lot of thinking and trial and error. What’s interesting is many companies have the same issues. I’m sure that among the thousands or organizations, someone has figured it out. I think this is where the power of collaboration and crowdsource can come in.

Last week, I tested the idea of crowdsourcing at a CBP Summit 2008, a Project & Strategy conference for Project Management Office directors and executives. Overwhelmingly, the audience felt peer collaboration with building best practices would be very helpful. Really, that’s why they go to these conferences — to get ideas from their peers. We presented a sneak preview of our PIEmatrix Crowdsource platform and it went better than I had expected. With this experience, we will expand this concept to include in our launch later this year. As we move forward, there’s a number of ideas we will share with our private beta users, such as how crowdsourcing will be self policing, how to provide quality transparency (i.e., ratings), and how an organization can place a call to invite the community to work on their best practice needs, such as how do I get that dang guy off the bridge.

I would like to get your thoughts or ideas. Please comment.

My last post introduced the “pie”. Today, I’ll explain how we turn a pie on its side to represent a matrix. To recap, many iterative project methodology models are circular. For example, in my last post, I chose slices (or project stages) Plan, Discover, Design, Construct, etc. Now, let’s take this two-dimensional pie and flip it on its side to show its edge. The side view is what I call the pie’s layer. Let’s say this layer is called Project Management. Under the first slice called Plan is a cell that aligns with Project Management. If you were to look in this cell, you may find process steps such as identify business needs, define budget, etc. Basically, the layers and their cell content can contain process methodology, best practices, or procedures steps.

As we all know, project management is only one factor in project processes. There can be others such as risk management, project implementation, or steps for a regulation. The idea of looking at the pie from its three-dimensional layer view is you can start to stack up more process layers, such as adding toppings to a cheese pizza. This is where the matrix becomes clear. The slices are columns and the layers are rows. What is interesting about this model is it forces each process methodology or best practice to align with each other.

Many companies are struggling with different process methodologies on large projects, each method having its own structure and nomenclature. Let’s say if an IT team is using the PMI standard for project management and the RUP method for the systems development life cycle. Now throw in an audit committee with their own process for Sarbanes-Oxley requirements. You end up with groups of people on the same project speaking different languages.

What if we formulated a pie-matrix structure that forces all team members to agree on the naming of the project stages (pie slices). Then add each process methodology as a layer. The simpleness is you now have stage alignment between standards. This is the basic model I created for the PIEmatrix platform and this was only the starting point. PIEmatrix is an open web platform and is process content agnostic, meaning its up to our users to enter any best practice content they choose. We expanded the platform to allow further integration of different standards with pointers across standards boundaries. We added project task management features for the front line team members, dashboards for governance, and an SaaS model where people can collaborate together from anywhere around the world, all speaking the same process language and working together on the same page.

This is my first blog post. I’m the founder of PIEmatrix, and as you would guess I’ll write about pies and matrices. But of course most of you have no idea about what I’m talking about since PIEmatrix is a new start up, which hasn’t officially launched. A couple of years ago, I devised a pie and matrix paradigm to better present processes for projects of all kinds. (More on the matrix later). The common circular shape lends well since most projects are iterative in some nature. Since it’s a pie shape, I logically named the stages/phases of a project “pie slices”.  So far so good? I’m sure many of you have seen this concept, so nothing new here. Now, since many love acronyms (sorry), I had to get something out of p-i-e and that’s how I thought of “process for implementing excellence”.

Going forward I plan to share ideas and hopefully get input on how better processes can improve excellence.