Disponível somente no TrabalhosFeitos
  • Páginas : 12 (2767 palavras )
  • Download(s) : 0
  • Publicado : 14 de janeiro de 2013
Ler documento completo
Amostra do texto
The Project Management System Maturity Model
By: Chris Vandersluis

The Project Management Maturity (PMM) model is a pretty hot topic these days. There are waves of consultants who are making a good living helping organizations assess their “project maturity level” which is pretty much always displayed hierarchically with more mature alwaysshown as being better than less mature. Proponents of the concept say the PMM model shows the capabilities of an organization to manage projects. There’s a whole conversation to be had about how organizations become more effective and I’m not sure just climbing the Project Management Maturity model necessarily gets you there. But that is a subject for another day. Whether or not you're a fan ofthe PMM model, there is another kind of maturity model that I've seen with organizations who use Project Management systems.

When we work with organizations who are deploying a project management system, it’s very common to find that the desire of organization is to reap the benefits of every single element of the new system they’ve just had demonstrated by the vendor. The client sees reportsand screens and workflows and functions that they’ve only ever dreamed of and they imagine a world where all that functionality works as smoothly in their organization as it does in the sales demonstration. It is usually unclear to the client that the demonstration data and demonstration configuration that is being demonstrated was carefully developed in order to showcase as much of the productas possible. In the case of Microsoft Project and Project Server, this may extend far beyond the single product to include the entire stack of technology.

The client sees screens that initiate from Windows SharePoint Services or from Microsoft Office SharePoint Server forms. They see functionality that touches Active Directory or SQL Server Reporting Services. They might see workflow fromBizTalk Server or Windows Workflow Foundation and displays that come from PerformancePoint. The flow of data might follow a storyboard or a use-case scenario that makes understanding the potential benefits easy but understanding the underlying technology more difficult.

When we arrive to actually deliver the functionality the client is interested in, we need to temper their desires to deployeverything at once with a reality check. The client needs to decide how it wants to do business before we can even consider configuring such functionality and whether it can be delivered out of the box, with configuration or with customization effort. There are some clients who are insistent that they deploy every aspect of the functionality they’ve envisaged and are prepared to dig in and do thedesign, training, learning and development of that solution as well as find the funding both in time and money to deploy it, but these organizations are the exception.

What is much more common is that the client elects to deploy the aspects of its new project management system to the level that it is already comfortable with. As the organization becomes more knowledgeable about both the systemand the underlying business processes, it will demand more and more of the system; becoming more ‘mature’ as it progresses. It’s a natural progression. As the organization’s understanding of a project management process that can be automated evolves, its demand for that automation evolves also. This natural progression is just like the Project Management or Capability Maturity models. Knowingthat organizations will most likely evolve along these paths has made us very effective at knowing where to put our efforts in making an organization effective. We tend to focus on those project system areas that we know have a better chance of adoption and of giving a return on the investment given the project system's maturity of the organization. Of course no two organizations are the...