1. Project Managers are professionals.

I’ve worked within numerous companies that treated their PMs as cheap (not inexpensive mind you), transferable, commodity-type resources.  In some cases, if you could type on a computer and take notes, you could become a project manager.  However, we must continue to push ourselves out of the habit of relegating PMs to project administrative duties.  I sympathize with project managers who only set up meetings, take copious notes for meeting minutes, and update other’s tasks in a project plan.  If this is what we expect from our PMs is it any wonder that project success rates continue to be so low?

Project managers should be leaders within the organization.  They should be empowered to drive and to deliver what the company expects.  Employee (or even consultant) engagement and enablement are key.  If lowered to the level of project administrator, not even the most experienced PM will be able to succeed.

2. PMs, I don’t need to know your title.

Some organizations have a multi-layered system of project manager job descriptions.  These may be encoded as project manager one to project manager five, or they may mirror the old Big Eight consultant titles of PM: Senior PM, PM Manager, PM Senior Manager, PM Director, and so on.  I have been a national lead, a project manager, a program manager, a program director, and a solution lead.   Do these titles mean anything? Not really. I expect you are more interested in my talents and skills, as opposed to simply my title.

PMs should be ranked by their capabilities, not their titles.  Have you managed a project that lasted more than 12 months?  Have you overseen a team of more than 50?  Are you good at tracking actuals, forecasting, and rationalizing variances?  How good are your team-building skills?  What about collaboration?  The axiom of not judging a project manager by their title seems apropos.  A predefined stair step of title promotions based solely on tenure is not appropriate; individuals should move up they demonstrate the next level of skill.

3. Implementation methods don’t need to impact a PMO

Although Waterfall is still here – and will be for a long time – the world continues to move to Agile. Package application development methods are different than either Agile or Waterfall.  And let’s not forget that product development is not the same either.  The PMO should be adaptable and able to meet the needs of the organization, regardless of the types of delivery methods utilized by the organization. Don’t forget, PMOs oversee non-IT projects and those do not have any application lifecycle management!

PMOs have holistic responsibility for delivery.  They collect details, provide visibility, and drive resolution to problems.  A delay in this process is a delay whether it be waterfall or product development based. Portfolio visibility is across the suite of initiatives, independent of the tools used to manage each. Let’s keep the focus on what a Project Management Office does and not be distracted by delivery methods.

4. Which software is right for the PMO?

Have you defined all your requirements for a new tool?  What about the requirements of the PMO’s key stakeholders?  Should you use one of the Magic Quadrant tools, leverage SharePoint, or custom build something in Excel?

First, focus on the processes.  A sophisticated status and portfolio tool will not benefit your organization if project managers do not understand appropriate levels of reporting status.  An engineered estimating solution will be less effective if your team does not know how to estimate and does not record actual hours spent. An application for automating portfolio management will not pay off if the organization does not understand the principles of prioritization and trade-offs. It is important to think about getting the organization to work effectively before trying to automate. There are many tools to do this effectively. However, it is essential that you do your prep in terms of roles, processes, and organizational change management. These identifications are important regardless of which tool you choose.

Let’s Connect!

Do you need further help on a program, project, portfolio management, or software evaluation and selection? Contact Us.

The post Let’s Talk Project Management appeared first on Transforming Solutions Inc..

Transforming Solutions, Inc. (TSI) was engaged by a top 10 public research university with a medical center to assist with technology transformation efforts for University Advancement to develop a comprehensive understanding of the current state of the technology infrastructure and use this information as a basis to inform the evaluation and selection of a new CRM system. As a foundation for this work, TSI was asked to spearhead a CRM software selection effort. These efforts were managed by the Assistant Vice President for Strategy and Operations for the Foundation. TSI has served as a transformation partner throughout the project lifecycle, including the execution of an IT needs assessment, change readiness assessment, business case development, organizational change management, requirements gathering, development of an RFP, system identification and selection, and business processes improvement training and execution.

TSI has frequently engaged in similar software evaluation and selection projects, and we aim to gather data to capture answers to the following questions:

• What technology is in place and used (and by whom) to perform various activities?
• How effective is this technology? 
• What gaps or opportunities exist to streamline processes and increase ROI? 
• Are there areas where the existing applications or resources can provide more value by being upgraded or by investing additional resources in training efforts?
• Are there risks that are apparent in the current inventory of technology?
• What is the “customer experience” or “constituent experience” as a function of the current processes? 
• What future state options should be considered moving forward?
• What platforms may be feasible alternatives to meet the defined functional and technical requirements?

TSI’s Approach and Role

Approach

Process Improvement Sessions

The software selection project provided a relevant platform for which to conduct business process improvement sessions with the cohort of practitioners. This cohort of documentors and facilitators conducted business process improvement sessions in functional areas related to Advancement including Gift Processing, Prospect Management and Research, Annual Giving and Membership, Finance and Accounting, Donor Relations, among many others. The facilitation teams actively engaged with stakeholders by asking reflective questions, identifying opportunities for improvement and areas of risk, and developing recommended action plans based on current and future state maps.  

An integral part of any software evaluation and selection project is the identification of functional requirements for a new CRM system. BPI sessions provide a platform to collect requirements.

Constituent Experience and Voice of the Customer Sessions

The University requested that TSI conduct a series of constituent experience sessions to assess change readiness and capture the unique needs of the employees and stakeholders to inform the evaluation and selection of a new CRM system. In order to assess readiness for change and capture the unique needs of the constituents and their needs and desires for a new CRM system, TSI team members partnered with the stakeholders to document and facilitate Constituent Experience and Voice of the Customer Sessions. The cohort of practitioners were trained in the facilitation and documentation of these sessions, whereby they collected points of pride, pain points, areas of opportunity, envisioned the future state, and gathered requirements for a new software system. 

Requirements Gathering

TSI facilitated and documented requirements gathering sessions as a part of the Constituent Experience and Voice of the Customer sessions by answering the following prompt: “In the desired future state, I need the ability to…”. Throughout the requirements gathering process, it became clear that while functional areas had requirements that were unique to their job responsibilities, there were also requirements that transcended throughout all areas. Some of these included flexible reporting functionality, customizable homepage dashboards, and in-system notifications. These requirements gathering sessions resulted in 1,215 unique requirements for desired functionality that were then divided amongst the project’s eight Lots:

• Lot 1 Core CRM
• Lot 2 Integrations
• Lot 3 Communities & Portals
• Lot 4 Online Giving
• Lot 5 Event Management
• Lot 6 Digital Marketing
• Lot 7 Data Catalog
• Lot 8 Implementation Services

Role

TSI facilitated all sessions during this engagement, including requirements gathering sessions, constituent experience, business process mapping, vendor demonstrations and training sessions, stakeholder training, reference checking calls, among many others. TSI also led the analysis of various scoring and evaluation factors, including:

• Functional and User Experience Scoring
• Technical Scoring
• Vendor Viability
• Reference Checking
• Total Cost of Ownership, Transition, and Support
• Cultural fit

At the end of the selection process, TSI developed a set of pre-final recommendations and analysis in collaboration with the project team. This iterative process culminated in a comprehensive final report that incorporated stakeholder feedback and data from the entire project. 

Results

The project team and TSI were intentional about collecting metrics to track progress toward goals in learning, process, and strategy. Some of this data included:

• 13 practitioners received in-depth training on business requirements and requirements gathering methods
• 56 processes were mapped and analyzed (current state, analysis, and future state) with TSI, practitioners, and stakeholders
• 176 total processes have been mapped as a result of BPI training efforts
• 40 current state, analysis, and future state process sessions held to capture existing and forward thinking processes and define requirements
• 20 requirements gathering, constituent experience, and voice of the customer sessions with functional area stakeholders
• 1,215 requirements were gathered as a result of BPI and Constituent Experience sessions, which will inform the selection of a new CRM system
• Metric tracking was established to monitor total numbers of: pain points, opportunities for improvement, technical and functional requirements, participating stakeholders, processes, and sessions held

The post Software Evaluation and Selection for Top 10 Public Research University appeared first on Transforming Solutions Inc..