projectified

And Circle Gets the Square!

Wow it has been a long time since I have posted. I would love to say that I have not had a free minute as an excuse but sadly I have had free minutes, not many but I have and I used them on my family instead of writing blog entries. Sue me. :-)

Some highlights since I last posted:

• Microsoft Office Project 2007 and Microsoft Office Project Server 2007 have shipped (along with the slightly less important to me personally: Office 2007 and a little product called Vista)
• I have been doing the technical editing\reviewing for several of the new books that will be coming out about Project 2007 and they are looking good. I’m doing one on SharePoint now and will have at least one more about Project and then one about Project Server that I will be working on later. I will let you know when they ship
• I have been working on some cool projects internal to Microsoft in the RPM space and on deploying Project Server to a few internal groups. Very fun stuff.

The biggest deal for me is that I submitted a paper to the Bill Gates ThinkWeek process and it was not only accepted but also read and commented on by Bill himself! There are over a 1000 submitted and only a handful are selected to be read by the broader ThinkWeek working group and an even smaller number are read by Bill and an even smaller number actually get feedback from Bill. So needless to say I was pretty excited. While I cannot comment publically about the exact subject of the  paper suffice to say that it is about Project Server and it was well received. :-) It got the right group of people talking about the right subjects and it increased visibility of the product and it’s role. Exactly what I hoped it would do!

For those that do not know what ThinkWeek is:

What is "think week"? It is a week that BillG sets aside roughly every six months to think deeply about a range of topics impacting our company and the industry. Microsoft full time employees are encouraged to submit papers for think week - topics for the papers are broad ranging: new product ideas, promising research, trends that will affect Microsoft or the software industry, explanations of new technologies, suggestions for improving product development, etc.

It has been a very productive couple of months, just not in terms of the “blog posts per week” metric I used to use! :-)

Strategy(ies)-to-Project(s): Representing the Complexities

Clearly a single strategy can be served by many projects and a single project can serve many strategies. The discussions I have had both in the comments of my previous strategy breakdown structure posts and in the emails I have received have brought up some very interesting points. I have gone from liking the idea of linking strategy directly to "elements" within a single project to thinking it was unnecessary and cumbersome and now back to liking the idea again!

I think there could be some really cool outcomes not only for the Organizational Strategy side of the house or the Portfolio Alignment side of house but also for the "PM or team member that just wants to have a better picture of where their hard work fits into the big picture" side of the house as well.

Strategy "Down" to Project Visualization

Linkages from Strategy "Down"

This would provide the organization with a more detailed picture of how strategies are being made to come true via projects and the deliverables of those projects. Linking specific deliverables to the strategy instead of the traditional method of linking whole projects requires a more detailed thought process to be involved. Whole projects would not be just dropped in the "Strategy A" bucket. Instead finite parts of the project would need to be analyzed as to how they support a strategy.

Project "Up" to Strategy

Linkages from the Project "UP"

This way of looking at the relationships offers a different perspective. This diagram would be useful for PMs and team members to more easily visualize how their project and even their particular part of a project supports the overall organizational strategy.

The other thing it would do would be to provide an interesting 'scope check' early in the project. Notice that the deliverables are not only numbered but they are numbered within a set of 4. Where is Deliverable 2? The question would be..."If Deliverable 2 does not directly support a strategy why is it there?" Certainly there are valid answers to this question. This is not to say that just because it does not have a direct strategy link that it should be removed but there is value in the question and value in the process required to adequately answer the question. Answering these kinds of questions and making these kinds of links might force us and managers and planners to think about individual parts of our project in a different way. It might make us examine our scope and our deliverables and the usage of our teams in a different ways. On the 'other side' of this same coin it might make us think about our strategies in different ways as well.

I very much want your thoughts on this. Please email me with your thoughts. I will NEVER share your name or contact info with anyone without first getting your specific approval.No details about your company, your name or your clients will ever be posted here without your specific approval.

Possible problems with the approach that need to be addressed

Nothing is perfect. There are issues with this approach

1. Breaking deliverables up and linking them directly may hide the fact that a project is not generally a disconnected set of unrelated deliverables. Tracking any one deliverable as being 'the' part of the project that supports a given strategy may not be effective in communicating the importance of the other deliverables. It would be important to ensure that this approach (of linking deliverables to strategies) was used with the right caveats and within a context of understanding the importance of the whole.
2. It requires a project organization methodology that contains "deliverables". In my opinion this is the ONLY way to organize a project but there are those that disagree. This approach would only work if your project was organized into chunks that could be linked 'UP'.
3. It implies Big Up Front Planning (maybe). This approach could be seen as being supportive only of "traditional" PM methods, which is to say it could be seen as NOT supporting the more "Agile" methods.
4. Any More? Email me PLEASE. I want to know what is wrong just as much as I want to know what is right! :-)

Tags: strategy breakdown structure, strategy, portfolio management

SBS Taxonomy

OK so I will take a first shot at what the levels of the SBS would look like.

Strategic Initiative
        Objective
                Program
                        Project
                                WBS

Just a shot into the thin air. How do you all (all 18 of you LOL) see this working? How would you like to see these levels broken down?

Do you see this kind of expansion of the strategic alignment idea as being useful? Is there value in breaking a strategic initiative down into chunks smaller than the initiative itself but yet still larger than the projects that support that initiative?

Email me with your thoughts.

Tags: project portfolio management, strategy, strategy breakdown structure

Strategy Breakdown Structure?

I was reading Demian's blog over on the ITToolbx family of blogs and he was talking about what he called WBS 2.0 and it's interplay with project portfolio management. It got me thinking last night about how strategy is (should be) connected to a new, broader idea of Work Breakdown Structure. Since the top level of a work breakdown structure (within it's currently held definition) is the project I was thinking about how the broader definition would necessarily change the W in WBS to something else. SBS came to mine initially for Strategy Breakdown Structure. If we start with organizational strategy as the driving force behind the management and alignment of the portfolio of projects then it makes sense that to get a decomposition of all the work that feeds up to those strategic goals that we would start with the strategy and work down.

So we start with the Strategy as "Level 0" in the SBS. What is the next level? Do we jump right to individual projects? Is there one or two intermediate levels between the strategy and the project level? What would those look like? What would we call them?

The more I think about this the more I like it as a way to help organizations do a better job of aligning projects to specific strategic initiatives particularly if there is one or two intermediate levels between the strategy itself and the project. I have found in many cases that the very broad nature of the strategy level being the buckets into which projects are placed that it is overly easy to put a project into a bucket without much analysis of why that project belongs in that bucket. It seems as if the strategy was broken down into smaller parts it would require some more thought about which one of the sub areas of that strategy the project supports.

So help me out with your thoughts on this. Email me at [email protected] with your ideas on this subject. I will compile them and share the findings here.

Technorati Tags: project portfolio management, strategy, strategy breakdown structure

Iterative Design\Build Loops in the Configuration of Project Server: First Pass and Initial Thoughts

I have always been a fan (and in fact a major proponent) of the idea of iteration in the long term deployment and roll out of Project Server across an organization. Myself and Russ Young of QuantumPM were one of the first ones to talk about this in the Enterprise Project Management Deployment Guide way back during the Project Server 2002 days. Our work in this area was based on ideas that were widely held not only in the Project Server consulting world but in almost all enterprise software organizations. These iterations were fairly large scale ones dealing with the staged, incremental roll out of Project Server to the many organizations within a larger organization as opposed to the massive one-time dropping of Project Server on the entire company. This approach started with a small but representative (as much as possible) group or small organization and then using the lessons learned from this group the system would be adjusted (new fields added, new views, server architecture adjusted, etc) and then another group would be added. This process would repeat until the entire organization was using the tool. Each iteration added not only new people but also new or fixed functionality in the form of views, security, process, etc. This method is now used by virtually every consulting company doing Project Server deployments.

The kind of iteration I’m talking about here happen on a much, much smaller scale and deal with the actual design and production of the configuration of the Project Server system for a given organization. Instead of dealing with the successive roll out to new organizations I'm now talking about the iterative design\build loops around adding new fields, views, security configurations within any one of those larger iterations.

Understanding of the Environment and the Problem(s) to be solved
This includes the collection of what the users want the system to do for them in addition to the observation of the system at work so that you as the consultant can help make suggestions.

Configuration\Build
From the knowledge gained so far the system is configured to the best of your ability. Fields, views, security, etc.

Simulations
most organizational uses of tools like Project Server revolve around the capture and editing of project data and then in the use of that data to make specific business decisions that effect the ability of the organization or project team to function with regard to projects. I look at kernel, the very core of Project Server’s use in an organization as the viewing of data via views or reports by decision makers. Everything else that project Server does supports this in some way or another. With this driving principle in mind the check or test of the configuration\build ‘stage’ is a simulation where decision makers use the tool as it is currently configured to simulate the decision making processes they must go through to manage their work\projects\portfolios\etc. These simulations have the decision makers using the tool in a conference room with the design team and other decision makers up on a projector. Talking through the decisions they need to make and what data they would need to see to make them. How it would need to be displayed, grouped, sorted, how it should be secured, who can see it, who can’t see it, etc.All effort toward a better understanding of how the tool will be used and what decisions it will be used to support.

Revisiting the build stage…
At this point we jump into a loop of Configuration\Build and Simulation loops that successively improve the suitability of the Project Server configuration to the needs of the decision makers that will be using it to run the business\projects\work.  If this means new views or fields then so be it. If it means configuring and rolling out the use of timesheets to those doing the work or the development of custom OLAP cube building routines to provide company specific data in Portfolio Analyzer views then that is fine too.The point is that the design\configuration happens based on simulated use of the product as it is configured currently.

___

This process can take place either prior to the system ‘going live’ or as part of the addition of new users to the system. Also, a variation on this process happens on an ongoing basis while the system is being used by the organization. As people touch the system and use it as part of their project management\portfolio management processes their new experiences and new expectations become, often, new requirements for the system. The administrator of the Project Server system should constantly collect suggestions and new requirements and evaluate them with the team for inclusion in the system. This constant updating of the product’s configuration ensures that it keeps up with the most current processes in use within the organization.

___

Obviously this is not rocket science and I'm not claiming to have ‘invented’ it by any means. I’m sure that many others are using similar processes for their Project Server (or other PM software) roll outs. I should also mention that this process is only suitable where the organization is able to devote several weeks (at least 3 or 4) to this initial design process. Often organizations that are rolling out Project Server have only a very short time to do their initial design and configuration. In cases like this the process laid out here may require too much time. But it should be said that while this process requires more time than many methodologies it is much more likely to produce a usable system. Shorter term processes get you up and running very quickly but at the cost of fully understanding the processes and needs of the organization.

This is just an initial layout of rough thoughts on this process. It is by no means final.