Friday, October 29, 2010

Selecting the Right Application

You've decided it's time to upgrade one of your core business applications - but where do you begin??

Many organizations immediately jump to solutioning without identifying what their true needs are. They decide the best alternative is to upgrade their existing system, or purchase a net new system, and then enter into negotiations with a vendor of their choice. While this may be an alternative, it may not be the best - or most cost effective approach for selecting a new application.

Identify Current State

Many businesses believe they have a pretty good understanding of their current state. They look at their existing business processes and quickly determine they are either too labour intensive or inefficient, and can be improved upon. While the business may 'intellectually' have a good understanding of their business, without documentation it becomes virtually impossible to communicate to a perspective vendor exactly what they want to improve. Any vendor engaged at this point is left to make assumptions - which inevitably lead to misinterpretations of facts. Organizationally, take the time to determine exactly what your current state is so you have a baseline on which to build.

There is another benefit you will recognize from this effort - although it won't become apparent until later on. Undocumented gaps in your processes will be accentuated when a new application is installed. You can be assured your staff members are relying on their own workarounds with the existing system – workarounds you may not be aware of. These undocumented shortcuts are precisely what will cause the most angst later on, as they will get missed during the requirements gathering stage and won't surface again until a new application has been installed – when those opportunities to side-step process are no longer available.

Analyze Current State

It is critical to not only document your current state, but to also take the time to analyze what the information is telling you. Does your analysis indicate there is a significant opportunity for improvement? If so, in what areas – and what changes need to occur to improve your overall business performance? Taking the time to analyse your current state may seem like you are not making progress towards changing out your present system - but in fact you have begun down a path that will greatly improve the chances of your organization making a good purchasing decision that will meet your future needs.

Identify Future State

You now have a pretty good handle on what opportunities may exist - it's now time to 'blue-sky' your future state. Consider what your business could look like. Which opportunities must be addressed to improve efficiencies, output or capacity? What types of technology is currently available in the marketplace that might fulfill those requirements? What are your competitors doing? These are critical questions to ask - as this step of the process will start to define your requirements.

Every step you take after you have identified your future state builds upon the previous steps - adding a new level of granularity. This approach defines what the requirements must look like to fulfill your future state vision. In other words, at the end of this process if you take the lowest level requirements and roll them up into what the system will look like - it should match your future state vision. This top down approach provides more clarity than starting at the bottom and working up - which is essentially what you are doing when you jump to solutioning without first taking the time to identify your needs.

Document Business Requirements

You've documented your current state to ensure everyone involved has a sound understanding of your business processes, reviewed business processes to determine if you have any undocumented gaps that need to be addressed, spent time analyzing what your current state looks like and where there are opportunities for improvement, and finally defined your future state. Congratulations - you are now ready to start documenting business requirements.

Evidence shows that around 70% of all projects fail to meet their objectives. Many believe a lack of clearly defined requirements is the cause. While this statement is 95% true, it is critical the sections outlined in this blog entry up to documenting requirements are implemented first. You can only effectively document requirements if you have a good understanding of what those requirements are in the first place. Spending time on the sections previously discussed prior to proceeding to the requirements gathering phase will drastically improve your likelihood of a positive outcome.

Complete an RFP

Business requirements will feed into the RFP (Request for Proposal) process. An RFP is a document outlining your requirements that asks a vendor to propose a solution they think will meet your requirements. They may propose their base application(s), their base application(s) with some minor configuration adjustments, or their base application(s) with entirely new modules written to support your business. The possibilities are endless as to what they might propose, but keep in mind if the requirements aren't clear enough for them to understand what your organization requires, the possibility of the proposal hitting the mark decreases dramatically.

Don’t cut corners at this stage of your application selection process. The more information you can give them up front - the increased likelihood the vendor will provide you with a proposal tailored to your needs.

If your organization is unfamiliar with the RFP process, talk with a professional management consultant prior to proceeding. RFP's have contractual obligations that must be clearly understood prior to releasing an RFP to limit your liability.

Make an Informed Decision

You are now ready to make an informed purchasing decision. You have identified and analyzed your current state, defined what your future state will look like, documented requirements to align to your future state vision, and solicited feedback from vendors. Scoring of the RFP will assist you with making the right decision. The next step - implementation.

If you would like to discuss any of the topics this blog entry addresses, please feel free to contact Innovalign at info@innovalign.com.

Monday, October 25, 2010

Defining the Role of the PMO

The PMO (Project Management Office) plays a key role in many organizations, but it's success is not just about the enforcement of the use of templates and methodologies. Many PMOs get caught-up in structure and formality and lose sight of what they should be - a support mechanism for assisting the business to successfully deliver key initiatives.

A PMO should always play a support role for the business, however more often than not when a PMO is deemed unsuccessful, it is a result of the PMO having morphed into a highly formalized, tightly structured department with enforced standards that become a barrier to the business. Over time, the business refuses to support the PMO as they feel the formality is unnecessary and too time consuming - and the result is the disbanding of the department. While the business feels this is the best alternative, it actually is a poor decision.

When a PMO is structured correctly - and the right objectives are in place, the PMO plays an important role in project delivery. The business should be able to rely on the PMO to support business initiatives, while at the same time, feel their needs are being met.

The Template Trap

How many different templates does your PMO have? 10? 20? 50? Has  your PMO developed a template for almost every situation, posted them into a central repository and instructed everyone they must be used under all circumstances - and if a pre-existing template doesn't satisfy a need, a new template is created and posted to the central repository -- never to be used again?

If this sounds like your PMO, they have lost sight of their key responsibility. In the situation described above, your PMO becomes a significant cost center as opposed to a support center for the business. While templates do have there place to ensure consistency amongst project delivery, they are not the end-all to be-all. Templates are simply a tool - and should be used only to assist the business formalize thoughts and ideas so they can be actioned. For example, a Business Case, Feasibility Study or Project Charter are key project documents. But they are key documents because they assist the business to 'think-through' the initiative they want to undertake. These documents are of more value to the person writing them, than to the PMO for having them. And yet, many PMO's look at these documents as simply a deliverable - and leave it at that.

The power of a PMO comes from their ability to understand key deliverables such as a Business Case, Feasibility Study or Project Charter actually serve a purpose. Most of the time, the PMO will shy away from working with the business on the development of these deliverables - the argument always being "it's the business's responsibility to tell us what they want." While this statement holds some merit, it is also a way to skirt the responsibility of actually 'helping' the business through the process. It's this attitude of 'we develop the templates and the business uses them' that over time causes the resentment between the two areas.

That's the Way PMI Says It Should Be Done

You have a number of project managers that are certified in their fields - they hold PMP (Project Management Professional) designations or are certified Scrum Masters or Prince 2 practitioners. Your templates and PMO methodologies are developed based on the methodologies of each of the different practices, and there is little to no deviation from them. Problem is - there is little to no deviation from those methodologies.

Increasingly, PMOs are adopting the PMI methodology. The nine knowledge areas PMI's methodology is built upon are implemented and followed, while at the same time templates are designed to align to each of them. While PMI has a solid approach to project delivery, it is not suited for all projects. If all the rigor PMI suggested was imposed for all projects, it would be virtually impossible to deliver a project within the allotted schedule and budget.  Flexibility to pick and choose the elements of different methodologies that best suit the situation is essential in successful project delivery.

Each one of these methodologies have their strengths, but no one in particular is the best. The PMOs that offer the greatest benefit to the business use a mix of different practices, recognizing some circumstances are better suited to different methodologies. These designations and certifications provide a toolbox of tips and tricks, but it's the maturity of the PMO that determines when each should be used.

Aligning Business Initiatives with IT Solutions

The business has completed the Business Case and Project Charter and the project is initiated. The project team  sets off to deliver the project, never to be heard from again. Sure, the communication plan states the PM will discuss project progress with the Project Steering Committee and Project Sponsor on a regular basis, but do they REALLY discuss the project - or are they just giving status updates? There is a difference.

The PMO should be taking measures to ensure all initiatives undertaken by the PMO on behalf of the business remain aligned with business requirements. The documents created at the beginning of the project might clearly articulate the objectives of the project, but within a relatively short period of time objectives (or the understanding of them) could easily drift apart. How many times have you attended a project status meeting where someone nonchalantly mentions something and you get the 'what?' response. It's at this time you realize the project is in trouble - one party assumed everyone knew what had to be done; the other party assumed they also knew -- neither were the same assumption. Not a situation a template or methodology will fix - only communication with the business could have prevent this situation.

A successful PMO does much more than template governance or enforce project methodology. The successful role of a PMO includes flexibility, understanding, listening, alignment, and assistance. Once a PMO losses their focus of being a support department, they start to become a cost center - adding little value to the organization. It is usually at this point the PMO is deemed worthless and disbanded, resulting in the business losing valuable project delivery insight.

If you feel your PMO has fallen into some of the pitfalls this blog entry discusses and you would like to discuss options for overcoming them, please feel free to contact Innovalign at info@innovalign.com.