Easy in theory, difficult in practice

Some organizations struggle to improve their PM or project portfolio management capabilities without having a PMO.  However, I’ve also encountered organizations that have established PMOs in multiple functional areas and at differing levels of authority – this situation is equally challenging.

Some of the risks of PMO proliferation are:

– Significant “hard” costs with limited perceived tangible benefits.

– A lack of process or tool consistency across PMOs results confuses PMs, resource managers, team members and other stakeholders and this in turn reduces the “bang for the buck” achieved from the overall organization project portfolio.

– Jurisdictional disputes between PMOs can impact credibility, cause communication issues and also reduce overall value received from a portfolio approach.

Large organizations may not be able to get away from having multiple PMOs, but a few ground rules can ensure that these risks are mitigated.

1. Ensure clear authority & mandate boundaries between the PMOs.  For example, if there is an enterprise PMO and a departmental PMO, project portfolio management processes at the enterprise level should be controlled by the enterprise PMO where as project management practices within a department can be controlled by the departmental PMO.

2. Ensure consistent project metrics across all PMOs.  The degree of discipline within each PMO’s methodology can vary, but the metrics that are reported for project status across different PMOs need to be consistent otherwise it is impossible to get an accurate understanding of overall portfolio health.  Beyond the nature of the metrics, the frequency of gathering or calculating of the metrics also needs to be aligned so that executives know that project data is up-to-date across the board.

3. Ensure resource management data and practices are standardized across all PMOs.  A critical foundation to project portfolio management is that organizations have to have a consistent, accurate, near real-time understanding of resource capacity and allocation.  If one PMO is tracking resource data at the individual resource level while another does it at the skill level, it becomes very difficult to look at supply vs. demand at the organization level.  Similar to the previous item, I recommend standardizing on a handful of resource metrics that are tracked in a consistent fashion across all PMOs.  However, as resources can work on projects that span the oversight of multiple PMOs, it is important that resource request, allocation, evaluation and release practices are also standardized across these PMOs to avoid confusion and improve integration.

4. Use common tools across all PMOs.  While the degree of project management discipline might change on a PMO-to-PMO basis, and some of the services provided by the PMO might vary (e.g. one PMO staffs the PMs for its projects while another only provides project oversight) the tools that are used to automate the PM processes should be the same.  If not, significant cost and resource effort will be required for integration, establishing an organization-wide resource pool becomes very difficult, and it is much harder to negotiate for enterprise license or subscription agreements with tool vendors.

Your organization may be experiencing the phenomenon of PMOs spawning like Mogwai dropped into a swimming pool, but this should not imply that the efforts of these disparate PMOs cannot be aligned towards (what should be) a common goal – facilitating the creation of business value.

(Note: this article was originally written and published by me in December 2009 on my personal blog, kbondale.wordpress.com)

Assuming your organization or department has a published project management methodology, chances are that it specifies that at least a few standard artifacts are created and maintained on every project. These artifacts might be standalone documents, or they might exist as a data set within a project management information system.

One of the most valuable pieces of advice in the PMBOK Guide is “good practice” does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project. As such, competent project managers arm themselves with a toolkit of practices to draw upon, and apply them based on the specific needs of a given project, the maturity of the team and organization, and regulatory or compliance requirements.

For example, on projects possessing a significant degree of requirements uncertainty, using iterative and interactive requirements techniques and artifacts which might help to elicit true needs would be beneficial whereas for those projects in which scope and requirements are very clear, traditional methods of requirements gathering would suffice.

Is there such a thing as a minimal list of project artifacts which should be created and maintained regardless of the size, nature or complexity of a project?

The benefits in defining such a list is that it would help to eliminate or at least reduce some of the contention which occurs when a project manager has to justify the need for specific practices with a sponsor or other key stakeholder who views such practices as being unnecessary overhead.

Here are five “must have” project management tools along with rationale for selecting these artifacts and the risks in not using them.

Charter

Whether this is a single page document or something closer to a high-level plan, the charter is the one tool which a project manager can wield to demonstrate that their project has been formally authorized and, when it is well written, it will help to align key stakeholders and the team towards the project’s expected outcomes.

Without an approved charter, it may be challenging for the project manager to engage the resources required to plan and deliver the scope of the project, and there is a greater likelihood of stakeholder misalignment.

Approved Plan

Agile fanatics might cringe at the necessity for this, but it goes back to the basic criteria which define a project - it is a temporary endeavor consuming resources to deliver unique outputs which will generate business value. In the absence of documentation which clearly states what will be delivered, by when, how, with what resources and for how much, it is likely that the project will either be cancelled prematurely when funding or time runs out, or branded a failure upon completion if customer expectations have not been set and met.

Two critical components of this approved plan are objective project completion and project success criteria – without those, the project may turn into a shuffling zombie from the set of the Walking Dead.

Current Forecast

It does no good to have an approved plan if you have no idea as to how you are tracking to it. The forecast will cover the same knowledge areas as defined within the approved plan and should be used as the basis for communicating project status. Without this, stakeholders are left to guess how a project is doing, and it will be difficult to detect negative variance trends in a timely fashion.

RAID log

This artifact provides a consistent, centralized method for managing the uncertainty native to project work. Without it, risks may go unmanaged, issues might not be resolved in a timely manner, actions may linger resulting in schedule and cost impacts and key decisions might be delayed or worse, made without appropriate governance oversight and subsequently reversed.

The accuracy, currency and completeness of this artifact provides good insights into the overall discipline and competency of a project manager as it is their ultimate shield. If a project manager is not concerned about self-preservation, how much would you trust them to manage your project?

Closeout Report

At a minimum, this formalizes the acceptance of a project’s outputs, identify exceptions and the owners for those, and provides the necessary authority to shut down the project and to release resources. While we have all worked on projects where all concerned want to run away as soon as the work has been completed, the absence of this artifact might result in post-project headaches if expectation gaps have not been addressed.

There is an elegant symmetry to this list – the charter and closeout report bookend the project, the approved plan and current forecast are ideally identical twins, and the RAID log acts as the main monitor and control tool.

Have I missed any artifacts which you feel are mandatory? Do you feel any of these Famous Five are unnecessary?

(Note: this article was originally written and published by me in February 2014 on Projecttimes.com)

One of the most common excuses I’ve heard clients use to explain why a commercial off-the-shelf (COTS) product implementation was not successful is that “the vendor misled us”.  While there certainly are a small percentage of vendors that might purposely mislead prospects during the sales cycle in order to secure a sale, the court of popular opinion combined with natural selection helps to keep their numbers in check.

The more common root cause of this perception is the expectation gaps between what the vendor sells and what the client is expecting.

The challenge is that it is rarely possible to create a requirements specification for an enterprise application to a level of detail required to ensure that a vendor’s product will meet all critical requirements (e.g. functional, performance, technical).  Even if you could create such a masterpiece, vendors have enough problems with completing RFI/RFPs, so a comprehensive specification would likely result in no better end result.

Another challenge with many COTS implementations is the significant upfront capital investment in hardware and software if an on-premise solution is procured and implemented.  To secure the best discount on licenses, procurement departments may prefer to do a bulk purchase even though this does imply significant up front cash outflows.  Now you might say that software contracts can be designed with an easy walkaway clause if requirements are not met – unfortunately, the same may not be true for the underlying hardware that was purchased.  Also, once an internal team has invested significant effort over the course of many months in a vendor implementation, it is very difficult to convince the team (or the end users) to consider a different solution even if that is the right thing to do.

Agile principles could also be adapted for use on COTS implementation projects to partially address these challenges.

1. Emphasize working functionality over documentation – instead of spending tremendous effort on developing RFPs or detailed requirement specifications, have your end users with facilitation from business analysts define the business processes being automated using stories or use cases.  Augment these stories or use cases with the bare minimum of performance or usability requirements (e.g. user should be able to complete story X with less than 10 clicks).  This requirements documentation will be used to both short list vendors and to guide learning and testing efforts.

2. Minimize up front investment – the focus should be on demonstrating working functionality with a minimum purchase of licenses and supporting hardware.  You want to be able to address all required business processes, so ensure you have representation from all end users/stakeholders but do this with the bare minimum required to prove whether the end user stories and performance/usability requirements are satisfied or not.  A reduced up front investment is one of the benefits of going with a SaaS solution over an on-premise one, although that benefit may be offset by limitations on feasible customizations to the solution.

3. Apply an iterative approach to fine-tuning and validating requirements – have your end users work with the vendor and the project team to configure, learn and use the software in a production mode during the first iteration.  Each subsequent iteration should be time boxed, focused on a prioritized list of stories or use cases, and should ideally allow for a walk-away clause at the end of the iteration if either the requirements for that iteration cannot be met or if the business feels that their needs for the overall project have been met.

(Note: this article was originally written and published by me in October 2009 on my personal blog, kbondale.wordpress.com)

It might not seem that long but The Matrix was released in theatres almost twenty years ago!  Beyond dazzling us with innovative special effects and reminding us that Keanu is the master of deadpan delivery, the movie provides good examples of how we deal with change as well as lessons in effective (and ineffective) change management.

Neo’s first reaction after the reality of The Matrix sinks in is shock & denial – “He’s gonna pop!“.  This reaction occurs in spite of the fact that he has been actively seeking the answer to the question “What is the Matrix?”.  This should be a warning to all of us that even those who we would consider are the early adopters for change may not be truly ready to absorb it when it hits.

Neo’s subsequent reaction highlights the sadness that many feel once they know the status quo is going to change whether or not they want it to “I can’t go back, can I?“.  However, over the remainder of the film we see Neo’s growing acceptance and finally commitment in both understanding the reality he is living in as well as his critical role in it. and , and finally his commitment to it.  He becomes the change advocate that Morpheus always believed he could be: “No one has ever done anything like this – That’s why it’s going to work“.

Neo’s final words demonstrate how far he has evolved in becoming a change advocate “I’m going to show them a world without you. A world without rules and controls, without borders or boundaries. A world where anything is possible. Where we go from there is a choice I leave to you.”

With other characters, change reception is not as positive.  Cypher’s interpretation of his removal from the Matrix is that he has lost his freedom instead of gaining it: “All I do is what he tells me to do. If I had to choose between that and the Matrix, I’d choose the Matrix.”  Cypher’s behavior shows how easy it can be for someone to slide back from acceptance to fear and anger if change is not properly managed.  Just think what might have been avoided if Morpheus had done a better job of either managing Cypher’s expectations or recognizing that he would never fully embrace the change.

Morpheus’ comments to Neo about those who remain plugged into the Matrix also demonstrates how people can actively resist poorly managed change even if it is in their best interests “You have to understand, most of these people are not ready to be unplugged. And many of them are so inured, so hopelessly dependent on the system, that they will fight to protect it.”

So what does Morpheus do to ensure that Neo embraces the change?

• He doesn’t candy-coat or mask the truth. “I didn’t say it would be easy, Neo. I just said it would be the truth.“
• He gives Neo choices. “After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.“
• He repeatedly demonstrates that he believes in Neo. “You see, you may have spent the last few years looking for me, but I have spent my entire life looking for you.“
• He progressively introduces the change to Neo providing support along the way through discussion, training simulations and finally reality. “Do you believe that my being stronger or faster has anything to do with my muscles in this place? Do you think that’s air you’re breathing now?“
• He unwittingly provides Neo with a stretch assignment to help accelerate his change adoption: “Morpheus believes in something and he was ready to give his life, I understand that now. That’s why I have to go.“
• He and his colleagues try to inject as much fun as possible into the change “Ju jitsu? I’m gonna learn Ju jitsu.“

Apply these practices the next time you are faced with leading a major change and you won’t need to worry about someone saying “Good bye, Mr Anderson!”

(Note: this article was originally written and published by an unplugged version of me in June 2014 on my personal blog, kbondale.wordpress.com)

A good practice with agile delivery is to keep team sizes small to reduce the number of communication channels. But when planning a product release which cannot be delivered by a single team or pod within a reasonable amount of time, we need to structure the work across multiple pods of five to a dozen team members working in parallel but also orchestrating release cadence and work item priority based on the dependencies between work streams.

So how should work be structured across the pods?

Focus on features or capabilities

Feature-centric pods take ownership for completing one or multiple features or customer journeys which will provide meaningful value to their stakeholders. For example, a pod working to launch a purchasing portal might deliver browsing and searching capabilities for users.

Benefits of feature-centric pods include that they will rarely struggle with demonstrating tangible progress to their stakeholders at the end of each sprint and as they have end-to-end responsibility for a customer-facing feature, the magnitude of coordination between pods to deliver value is reduced. Should funding for the product run short, there is a greater likelihood of delivering some key functionality to their customers.

While feature focused pods align well to the “what”, from a solution design perspective, there is an increased requirement of cross-pod collaboration to ensure that data models and design approaches are aligned, and there could be specific enabling capabilities which get distributed in this model but which might have been better delivered by a single pod. Specialized competencies might also need to be stretched across multiple pods if the features each pod is delivering requires those skills.

Focus on components

Component-centric pods divide work based on a defined solution design or architecture. For example, one pod might take ownership for data interfaces while another is responsible for user experience. This model resolves the concerns with the capability-centric approach but introduces the need for greater discipline from an integration testing perspective and can make it challenging for individual pods to be able to demonstrate tangible evidence for what they have achieved to their non-technical stakeholders. Given the higher degree of feature-based cross-pod dependencies, productivity differences between pods can also cause greater impacts than with a capability-centric approach.

So let’s be pragmatic with our approaches!

Sometimes, the right answer might be to use a hybrid of the component and capability models. For example, if multiple capabilities are relying on a solid data foundation, a pod might take on that work and start earlier than other feature-based teams to address foundational dependencies.

(Note: this article was originally written and published by me in December 2016 on my personal blog, kbondale.wordpress.com)