Ian Sutherland
Ian J Sutherland| Kellian Consulting
Broxbourne, Herts, United Kingdom
I am new here so forgive me if I cover old ground. I have just taken up appointment as head of an existing Programme Management Office. There were problems with the set up and my appointment was part of the effort to stengthen the function.
I am facing many challenges and the information I have found both here and elsewhere has been very useful. Currently, while not (yet?) upsetting the status quo I am reverting to first principles as it is not clear to me exactly what the mandate is nor what the concensus of expectations is. I have a simple rule; if I don't understand it, I don't expect anyone else to. Following from this is that if people do not understand your teams purpose then you will have great difficulty delivering to any but the lowest of expectations.
Anyway the question in hand.
I have inherited an expectation that we (read "I") will choose and implement a PMO Tool shortly ie to fit within and utilise this year's budget.
From previous work I am aware of a few products and my new colleagues have a few others in mind. The purpose of such a tools and its benefits are again a potential source of confusion and subsequent dissatisfaction.
I am aware that there are a types of tools that appear to compete in this space. There are workflow/collaborative tools (same sort of space that Lotus NOTES occupied) where they are largely document based with workflow. These do not offer inbuilt Project/Programme management knowledge, but as always the promise is that it is easy to implemnet!!! At first glance a product from Intraspect would fall in this.
There are a few tools that are more centred on a database application where all information relating to projects/programmes is captured (once?!?) and then available. This provides (potentially!) a strong modelling, control and reporting tool, but is not really doing anything for document management. Products like ChangeDirector and PAT seem to fall here. iTools looks like it falls here though it does profess to document management too.
The third group I have seen appear to be communication, delegation and reporting tools, like Hydra.
I am sure I have grossly simplified this analysis, so I wondered if anyone is aware of any work that has been done and is available that positions the various offerings made to PMOs such that I can begin and education process here and from that drive out a focussed requirement definition?
Saving Changes...
|
|
|
Mark Price Perry
Business Driven PMO Evangelist| BOT International
Orlando, Fl, United States
Ian, congratulations on your new assignment and good luck heading your Programme Management Office. In response to your post regarding positioning of the various PMO offerings, allow me to comment. Firstly, there are number of credible sources such as the Gartner Group that position vendors and their offerings for Enterprise Project Management and Project Management Offices. The Gartner Group EPM Magic Quadrant report is an excellent positioning of just that. The Gartner Group in their presentations of the various vendor offerings often preface their vendor analyses with an understanding that vendor features and functions and bells and whistles, while very important, are in most cases secondary in importance to a PMO's committment to project management as a disclipline, adherence to project management processes to execute the discpline, and then use of functional tools to support the process. Gartner often posits, and I agree with, the notion of a solution architecture-based approach to setting up and managing your PMO. This makes a lot of sense. An architecture approach enables you to use your existing IT infrastructure and best-in-class choice of vendor products to meet your PMO and EPM needs. Typically, the components of a PMO or EPM architecture are as follows: 1) project management functions, 2) enabling platforms, 3) end user products, 4) server applications such as PeopleSoft, SAP, etc. and 5) your PMO project/portfolio management processes and best practices. For example, in the Microsoft Office EPM solution, the solution architecture can be seen as: 1) Project Server and Project Professional for the project management funciotns. 2) the enabling technologies that include Windows Server, SharePoint Server, and SQL Server. 3) the functional user products include Outlook, Word, Excel, PowerPoint, Visio, etc. 4) the server applications can include the customer's existing or choice of line of business and financial applications such as Great Plains, SAP, PeopleSoft, etc. and 5) the project management processes for de facto standards such as PMBOK, SDLC, GTM, etc., can include in-house developed methodologies or vendor solutions for project and portfolio managment processes such as BOT International's Processes On Demand, PM Solutions PMCoP, etc. You are quite right in that the collaboration platforms typically do not have project management functionality and the project management applications typically do not have collaboration and document management. And neither of the offerings typically have any kind of usable solution for PMO project/portfolio management processes and best practices. Hence, a solution architecture approach allows you to set up your PMO, use as much of your already existing "and paid for" IT infrastructure as you can, and then address additional vendor products to fill out your PMO architecture. Ideally, your choice of vendor products to improve the PMO would be based upon your lessons learned feedback and continuous improvement recommendations by your project managers, rather than vendor sales pitches. In summary, though this may not be the case in your organization, most firms tend to err on bringing in costly PMO applications prior to upper management's committment to the PMO, project management as a discipline, and the establishment of agreed to PMO processes and best practices that are used and continuously improved upon. To avoid that error and to avoid the vendor confusion of who has the best product, I would advise pursuing a PMO solution architecture approach, rather than a one product offering approach. And I would focus one tool selection only after having first established the agreed to PMO processes and best practices. While you can expend a great deal of time and energy developing from scratch you PMO processes, you might want to look at some of the leading marketing solutions for PMO processes such as BOT International's Processes On Demand, PM Solutions PMCoP, Tensteps, and others that can reside on your intranet, work with your choice of collaboration platforms such as Lotus, SharePoint, and others, and be easily integrated into your choice of PMO and Enterprise Project Management products such as Niku, Planview, Project Server, and others. Think about this. We have all seen a number of very good project management applications fail due to lack of an adequate PM process. Has anyone ever seen a very good Project Management Process fail for lack of an adequate PM tool..? Hope this helps. In the spirit of full disclosure, it should be noted that I work for BOT International, a software provider of project management process solutions for PMOs. Having set up over 100 PMOs, I have a strong process, rather than tool, bias as did the famed Edward Deming in his quote, "95% of the problem is due to the process, only 5% is due to people and tools." Hope this helps. -- Mark Perry, Vice President Customer Care, BOT International
Saving Changes...
|
|
