Sunday, January 01, 2006

Project Portfolio Management PPM: Service Providers ...

Professional service firms require project portfolio management (PPM) software that is comprehensive and integrated. The major ERP firms are delivering enterprise services automation modules. Neil Stolovitsky explores the special needs of the professional service organization. ...

... "PSOs want complete PPM solutions that address their business as a whole. For service organizations, efficiently capturing time, billing, and expense data is a key component to bridging projects and operations. " ...

Project Portfolio Management PPM: Service Providers: Via Tech Eval Centers: Project Portfolio Management for Service Organizations: Bridging the Gap between Project Management and Operations

Additional resources on project portfolio management for professional services:

Primavera Receives Strong Positive Rating in Analyst Firm's 2005 PPM for Professional Services Marketscope, Primavera, Project and Portfolio Management: "Primavera Systems, Inc., announced that Gartner has rated the company Strong Positive in its report, MarketScope: Project and Portfolio Management (PPM) for Professional Services, 2005, dated June 22, 2005 by Matt Light, Daniel B. Stang and Nicole S. Latimer-Livingston. According to Gartner, a company designated as Strong Positive is a solid provider of strategic products, services or solutions. Current customers should continue investments, while potential customers should consider this vendor a strong strategic choice. "

Via Tenrox: PSA software Professional Services Automation Solution: "Tenrox PSA software is a modular solution to automate project opportunity management, project initiation, workforce planning, time and expense reporting, project accounting, billing, invoicing, and executive dashboards"

Via Epicor Software: Epicor for Professional Enterprises: "Epicor is well positioned to face these challenges with you by delivering an intuitive and comprehensive enterprise service automation (ESA) application, Epicor for Service Enterprises. More than just professional services automation (PSA), it manages and streamlines virtually every aspect of your service organization - from bid management to engagement delivery and resource management to project accounting, portfolio management and beyond - all within a single solution. "

Professional services firms require a fully integrated and comprehensive approach to project portfolio management software ...

Labels: , , , , ,

Saturday, October 08, 2005

Planning for Project Initiation

Here's another of those questions that comes up during consulting engagements, particularly those where resource planning is an important management process.
Many organisations have a formal point at which a project is recognised as being part of the portfolio. Once a project is recognised as being official in this way, then it gets general visibility - it will have a name, perhaps a reference number, a project manager, a charter, a budget, a place on the executives regular status report, etc.
Frequently there is some kind of gate meeting for those organisations that use a Stage Gate Process. For others there may be a portfolio review committee or perhaps it's as 'simple' as getting three separate VPs signatures. Whatever the method, a common requirement is that there must be supporting information giving some kind of cost benefit analysis and, usually, more detail on probable timing, resource requirements, risk assessment and so on.
This information takes time, effort and resources to prepare. And there can be a lot of time, effort and resources involved. The issue is how does one plan for it when, technically, there is no project. There are three general approaches. Which one an organisation uses depends on its management and accounting practices and priorities.
  1. Start tracking the project from the time of very first idea. Once it becomes 'official', there needs to be a way to include the effort spent in preparing the proposal in the newly approved budget - including the cases where the project gets rejected at the first gate. This approach would be relevant where the organisation is really interesting in total product costs. The problem is that there is no official plan at the outset against which time and costs can be recorded - and this makes resource planning difficult.
  2. Have a specific proposal preparation project with it's own budget and approval mechanism. This would be relevant for major projects and often fits in the context where each phase of a major project would have it's own methodology, plan, budget and approval mechanism.
  3. Have a pseudo project which covers 'early project activities' with resources and budget to do a range of relatively lightly defined activities. In this case there would be little formal connection between the effort for the early project proposal effort and the eventual full project. This approach would be suitable for an organisation where project proposals are fairly simple and the effort required for an individual proposal can be approved under a fairly large umbrella.

Labels: , , , , , , , ,

Wednesday, September 28, 2005

Project Resource Planning; Is there a Gap in the PMBOK?

According to the PMBOK and traditional project management practices, project initiation begins with the project charter. Never mind that the real value-add is in the preparation needed to tie the project to organizational strategy (which arguably links to the portfolio management process) and to select the right project approach (which would end up on the charter). Ideally, the project manager should be more involved in up this up-front options analysis, which would also require solicitation of specialized resources very early in the game.

In addition, the subsequent planning processes include WBS and schedule development (both of which are best done as a group effort with stakeholders, as the PMBOK points out), yet there is no mention beforehand of soliciting resources for that work. These stakeholders are not often readily available, so this appears to be a gap.

Although the PMBOK rightfully suggests engaging stakeholders in the initiating and planning processes, the first time resource planning is mentioned in the PMBOK is following the schedule development. Could it be that the PMBOK doesn't consider stakeholders resources?

Yes and no. As it turns out, the PMBOK assumes these resources are readily available, as part of what it calls "Enterprise Environmental Factors." This might relate to the fact that many organizations (and remember, the PMBOK exists to document common practice, hence the name "standard") do not track resources during initiation and planning, but only begin doing so during execution.

Ultimately, the initiation and planning phases drag out because stakeholders aren't available and/or nobody is tracking progress during these phases. Some organizations are starting to realize the benefits of planning and tracking the "initiation and planning" activities (instead of planning to infinite capacity), so by the time the next PMBOK rolls around this might be common practice.

So, maybe this isn't a gap in the PMBOK after all, but instead, a gap in common practice.

Labels: , , , , ,

Sunday, September 25, 2005

Project Management "Front End Loading" Myths and Misconceptions

Here's a good presentation from Charles A. Clerecuzio and Paul Lammers on the myths and misconceptions of Front End Loading (i.e. the early initiation phases of a project).

We've had some postings here on the criticality of getting projects started on the right foot, and this paper certainly supports that approach, stating that Front End Loading can reduce overall project schedule and cost significantly. Check it out (once there, click on the PDF link for best readibility)...

FRONT END LOADING: MYTHS AND MISCONCEPTIONS: "Charles A. Clerecuzio"

Labels: ,

The Project Management Transformation: A Popular Goal ...

The Project Management Transformation: A Popular Goal: Via PublicCIO: Introducing Innovation ...

Justine Brown writes about a popular goal in many enterprises: the project management transformation. She explores the transformation at the New York City Housing Authority, which embarks on a disciplined project management process to enable more successful IT projects ...

... "The initiation phase sets out a business case that makes the ROI up front -- that makes certain recommendations as to the solution; what the alternatives, inherent risks [and] assumptions are; how possibly to procure it; what resources will be involved internally and externally, etc., said Heller. The Operations Committee must approve the project for it to move to the planning phase, which identifies project requirements, such as potential technologies and resource/cost requirements, and sets the stage for the remainder of the project, which continues through the remaining phases until complete -- assuming it meets each phase's strict entry and exit criteria. ... " ...

The project management transformation is a key goal of major enterprises today ...

Labels: , , , , , , ,

101 Project Management Uses for Mind Mapping Software

OK, maybe not 101, but I can think of at least six uses:

1) As a graphical way to capture goals and objectives during project initiation
2) For brainstorming solution ideas
3) To facilitate WBS planning and creation
4) To facilitate issues management in a more organized fashion
5) For brainstorming project risks
6) For capturing lessons learned throughout and after a project

Most mind-mapping software (which allows drag-and-drop functionality to sort ideas by category) is inherently easy-to-use, and allows for a quick and graphic way of sorting ideas and issues, especially when done in a group atmosphere.

Mind Manager from Mindjet is a good example, and it even exports to MS/Word, Powerpoint, and MS/Project. Check out their site below for more details...

Mindjet: Software for Visualizing and Managing Information

Labels: , ,

Saturday, September 17, 2005

Managing the Front-End of Projects; Is it Part of the Project?

There has been some good discussion as a result of my post on September 15th on the "impact of initiation and planning on the project budget." Managing these early phases well is truly a gap in the project management field and there doesn't seem to be industry consensus on whether these phases (known as Front-End-Loading or FEL) should be part of the project or not. Traditional thinking seems to place FEL outside the realm of project management, as a separate entity, with project management only getting involved once the resulting charter is established. Yet, this is odd, since Front-End-Loading plays such a significant role in project success.

The paper below, from the proceedings from the 2005 PMI Global Congress in Edinburgh (be sure to click on the link for the PDF version for best readibility), makes a good case for including FEL as part of the project. At the very least, we need a way to better integrate these strategy, conceptualization, governance, and early planning activities with the project itself.

Managing the Front-End: how project managers shape business strategy and manage project definition

Labels: , , , , , , ,

Thursday, September 15, 2005

The Impact of Initiation and Planning on the Project Budget

For those familiar with Earned Value, we know that the calculations require a baseline (which get created at the end of the planning phase), as well as actual costs.

But what about all that time spent during the all-important initiation phase (which should include some sort of conceptual planning and alternatives analysis) and the planning phase (which includes WBS and schedule development)? These happen prior to Earned Value tracking.

Typically, there will be quite a bit of time spent in these phases, and by the time the baseline is approved at the end of these phases, a big chunk of the budget has already been spent. Since we can't use Earned Value during those phases (no baseline exists yet), how can we avoid blowing our budget too early?

I've seen several approaches to this:

1) One approach is to create the initiate phase in the project schedule immediately upon starting a project. Begin tracking time immediately. Consider starting with a baseline (i.e. budget) for that phase, and tracking against "budget" just like you would the rest of the project. The problem is that it's hard to budget for this type of activity.

2) Another approach is to do the initiation work (conceptual planning, initial requirements gathering, preliminary scope and business case development, etc.) outside of the project, and begin the project with the charter resulting from that "early initiation" activity (typically just after project approval). As Max Wideman said on his site, there's not really consensus in the industry if these "front-loading" activities should be part of the project or not. Still, you'd need track the WBS and schedule development, but at least those activities are easier to get a handle on.

3) I've even seen companies not bother tracking time until the schedule has been created and baselined. All initiation and planning phases are outside of the project. Sometimes they don't even submit their project for acceptance until after the WBS and schedule have been created. Most companies want the first approval earlier, though, based on an order-of-magnitude estimate.

I'd be curious to see what other approaches may exist for controlling (or not) the time spent on the initiation and planning phases.

Labels: , , , , ,

Wednesday, August 31, 2005

Managing Projects Like a Consultant

One of the most important parts of a project (and most often overlooked) is the project initiation phase. This phase sets the tone for the entire project and makes all the difference iin the world for a smooth execution phase. With this in mind, how we approach it is critical.

Dr. Glenn Strange has written an informative paper describing a "consultancy approach" to project management. Pay special attention to his Project Initiation Checklist of Requirements at the end.

Project Initiation - a consultancy approach

Labels:

Saturday, August 27, 2005

Project Management: Business Vision

Project Management: Business Vision: Via Accenture: Information Technology: Too Big to Fail?

Achieving a shared business vision of project outcomes is essential to success. A simple, compelling project vision may be all that is needed to shift the balance in your favor. Investing time in the project initiation phase pays dividends in the future. Hugh W. Ryan writes about field-tested techniques for successful IT project risk management and discusses the approach for a business vision ...

... "A Business Vision. Time and again we heard that successful large complex systems projects begin with a vision of a potential new way of doing business. Moreover, the entire project is guided by whether or not a new initiative or a change in scope is faithful to that vision. How complicated does the vision need to be? Often, not very. In fact, the simpler the better. At one international stock exchange, for example, the business vision was simply a crisp articulation of the eight essential capabilities that the final system was to provide. But that simple vision carried a great deal of weight, primarily because the project team spent considerable time up front getting senior executive support for the vision. " ...

Achieve a shared business vision for your project to enable future success ...

Labels: , ,