projectmanagement

Top Secret! Successful Program Management In Government

| Jeremy Brien

Case Study Review: Milestones To Efficiency and The Factors That Influence Program Success In U.S. Federal Agencies

Formal project and program management has not been as diligently applied in government agencies relative to their counter-parts in private industry. This is alarming, as a large percentage of organizations, both public and private, are unable to deliver their projects successfully — “nearly 56 percent of strategic initiatives meet their original goals and business intent” (PMI, 2015). As a result, organizations are “losing $99 million for every $1 billion invested in projects and programs” (PMI, 2018). That’s roughly 10 cents per dollar spent on a project initiative. This article is aimed at summarizing the case study performed by the Project Management Institute (PMI) in 2015. The full case study can be found here.

Using Organizational Project Management — OPM

Just over a third of government agencies report that they “fully understand the value of project management” (PMI, 2015) and this case study examines three Federal Agencies to demonstrate what “successful Organizational Project Management (OPM) looks like in government” (PMI, 2015) in the:

  • Social Security Administration (SSA)
  • Bureau of Indian Affairs (BIA)
  • Federal Aviation Administraiton (FAA). 

Success Factors

While the specific mission and goals of each agency are unique — they all strive to effectively manage their budgets and spend tax payers money wisely, serve their constituents, and adopt and realize the benefits of OPM within their respective programs and projects. Below is a list of the success factors all three agencies report as

  1. Strong Leadership Capabilities: Hands on leadership from program managers effectively support project management activities, better engages stakeholders, and “serves to increase camaraderies and confidence within the team (PMI, 2015).”
  2. Commitment to OPM: Each agency had a subject matter expert (SME) available or leading the adoption of OPM; investment in training and certification made “formalizing principles and practices” (PMI, 2015) much easier and the appetite for change outweighed risk & avoidance. 
  3. Executive and Senior Level Support: Executives budgeted for training and were called upon when their influence was needed to remove project impediments — signaling a “strong sign of commitment to lower echelons” (PMI, 2015) of the organization. 
  4. Effective Training Programs, Ongoing Coursework, & Certifications: Training and experience go hand and hand; critical employees were afforded training and certification opportunities to better serve their constituents.

    “For the team involved in the Bureau of Indian Affairs program, to lower violent crime rates, Indian Country police officers received sensitivity training. This familiarized them with Indian cultures and customs, helping officers to avoid cultural missteps. This in turn helped promote acceptance of the program.”

  5. Transparent and Effective Communication: Regular communication, both formal and informal, were highly effective as they fit the needs of stakeholders and the programs, resulting in “identification of problems that could be pre-empted — reducing the likelihood of escalation” (PMI, 2015). 
  6. Team building and Stakeholder Engagement: Coalesced communication, training, and agency buy-in culminates into shared “understanding and respect among parties, which helps avoid resistance and misunderstanding that can lead to delays” (PMI, 2015). 

Common Obstacles

Each agency identified obstacles that were unique to their programs and mission, however, two common obstacles were identified:

  1. Lack of Understanding: Specifically, understanding the value of a project or program management.
  2. Limited Funding: Resources are finite and government agencies must carefully budget and distribute their funds across multiple portfolios, programs, projects, and operating activities. 

Lessons Learned

The Project Management Institute has not performed a study on the adoption of Organizational Program Management in Government Agencies prior to this case study. The case study servers as a baseline for future research and the impetus for other agencies to collectively learn and increase adoption of OPM.

Lessons Learned By Agency

  1. Social Security Administration: “Project and program career development benefits the entire organization” (PMI, 2015).
  2. Bureau of Indian Affairs: “Project and program management practices can be implemented to fight crime and promote better understanding between police and the community, thus creating efficiency and lowering the violent crime rate” (PMI, 2015). 
  3. Federal Aviation Administration: “Greater reliance on standardization of processes transforms program management at the FAA” (PMI, 2015). 

I’d love to hear your thoughts on OPM or any experience you’ve had with program and project management you’ve seen in government. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

 

References

Project Management Institute. (2014). PMIs Pulse of The Profession: The High Cost of Low Performance 2014. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2015). Milestones to Efficiency: Factors That Influence Program Management Success in U.S. Federal Agencies. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Project Management Institute. (2018). PMIs Pulse of The Profession: Success in Disruptive Times. Project Management Institute Global Operations Center. Newtown Square: Project Management Institute.

Scrum Product Owners Part 2

| Jeremy Brien

The Product Owner Chooses Business Value

As the “single wring-able neck,” the Product Owner is tasked with maximizing business value and setting the direction for a new or existing product. She shares the guiding view into the future and collaborates with customers, stakeholders, technical teams, and supporting roles to steer the product to the desired end-state. In this article, I would like to share my favorite two value areas that effective Product Owners understand.

  1. Customer Service
  2. Operational Efficiency

1. Customer Service

An organization is nothing without it’s customers — they are either external or internal customers. Customers are the people who use the product to fulfill a specific need. A product that is easy to use and accurately fulfills a customer’s needs is valuable to the organization. Design considerations like User Interface and User Experience need to be considered when crafting user stories, however, the main consideration is, “how are we best serving our customer with this feature?” 

External Customers look to “exploit artefacts[sic] produced by the organization with specific requirements and specifications” (Hobbs, 2016). External customers are essential to the success of the organization as it operates to produce the artifacts specified by external customers.

Internal customers are all members of the organization who rely on assistance from each other to fulfill their duties in the production of artifacts specified by the external customers.

“If you build a great experience customers tell each other about that. Word of mouth is very powerful.”

— Jeff Bezos, Amazon

2. Operational Efficiency

An organization is unable to best serve it’s customers if it’s inefficient. While running the air conditioning in the middle of winter is wasteful, Product Owners go beyond the obvious to make operations more efficient. Below is a list of operational efficiencies in a ‘lean’ context that Product Owners should consider in their user stories. Product Owners should start with, “how does this feature improve our operations or reduce waste?”

  1. Reducing defects – features aimed at reducing defects strive to reduce errors, mistakes, rework, and preserve data integrity of internal and external customers.
  2. Reducing motion – features directed at reducing motion strive to automate a formerly paper-driven process. This helps improve efficiency and standardizes the quality of those processes. Additionally, frees up resource capacity so internal customers can engage in more technical work.
  3. Creating a common language – features sighted on centralizing information in a common place creates a lexicon synonymous with the organization. It simplifies the way information is shared and understood throughout the organization. Internal customers are all speaking and sharing the same meanings and when extended to client-facing applications, external customers speak the language too.
  4. Improving decision making – features trained on increasing transparency allow internal customer to make decisions quickly — ultimately helping organizations exercise business agility and ‘pivot’ when the internal or external environment prompts for it. 

Leave your thoughts on Product Ownership or Business Value in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Sources

Hobbs, B. &. (2016). Projects with internal vs. external customers: An empirical investigation of variation in practice. International Journal of Project Management Volume 34, Issue 4, 675 – 687.

Related Posts

Scrum Product Owners Part 1: The Product Owner Steers The Ship

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Six Elements Of An Effective Strategy

Agile Leaders Understand Customer Service and Culture 

 

 

 

Scrum Product Owners Part 1

| Jeremy Brien

The Product Owner Steers The Ship

The Product Owner can be described as the “single wring-able neck” in Scrum. They are responsible for maximizing value and setting the direction for a new or existing product. They work with development teams, stakeholders, groom & prioritize their backlog, and share a guiding view into the future. The Product Owner is the most important role in the organization and only a special kind of person volunteers for it. The rest are usually ‘volun-told.’

Intention and style shape the effectiveness of a Product Owner. Like all of us, Product Owners come from different backgrounds or roles. Angela Druckman, of the Druckman Company has a wonderful series on Product Ownership and I have personally worked with her and attended her Certified Scrum Master and Certified Scrum Product Owner courses during our Agile Transformation at the Nevada Department of Transportation.

As a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles.

“An anti-pattern is something that looks like a good idea, but which backfires badly when applied.”

-Jim Coplien

Never assume that an ex-project manager uses “command and control” with their teams or that ex-business analyst will struggle with emotional intelligence. Leave all judgement to Judge Judy. Your job as a coach isn’t to fix anti-patterns. It’s to tap into people’s potential. Anti-patterns will extinguish as each person’s potential is unlocked and the agile mindset becomes a part of who they are. 

Captain & First Mate: Product Owner & Scrum Master

The first thing I want to stress is the relationship between a Product Owner and Scrum Master. These two roles, when combined with the Delivery Team, are a lot like a Project Manager and Delivery Team. Let’s take a 30,000ft view of the 10 Knowledge Areas of Project Management and see where the Product Owner and Scrum Master have responsibility in regards to traditional project management and its’ relation to iterative product development.

  • Integration Management
    • Traditional: This responsibility falls onto the Project Manager via a Work Breakdown Structure (WBS) and Gantt Charts.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master via collaboration and iterative development.
  • Scope Management 
    • Traditional: This responsibility falls onto the Project Manager and Change Control Board via the Scope Baseline and Change Management Process.
    • Scrum: This responsibility is the Product Owner’s via collaboration with stakeholders, prioritizing business objectives, and the product backlog.
  • Cost Management
    • Traditional: This responsibility falls onto the Project Manager via the Cost Baseline, budget, and Change Management Process
    • Scrum: This responsibility is the Product Owner’s via iterative delivery, business objectives, and budget.
  • Time Management (formerly Schedule Management)
    • Traditional: This responsibility fall onto the Project Manager via the Schedule Baseline, critical path, and Gantt Chart.
    • Scrum: This responsibility is shared among the Delivery Team and Product Owner via iterative releases.
  • Quality Management
    • Traditional: This responsibility falls onto the Project Manager and delivery team via Quality Assurance (QA), Quality Control (QC), and User Acceptance Testing (UAT).
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner via Quality Assurance (QA), Quality Control (QC), Sprint Reviews with stakeholders & Product Owner, Scrum Master resolving impediments during the daily stand-up, and Agile Retrospectives.
  • Procurement Management
    • Traditional: This responsibility falls onto the Project Manager and stakeholders via the organization’s Project Management Office procurement Policies, Processes, and Procedures
    • Scrum: This responsibility is not defined in Scrum, however, the organization’s Policies, Processes, and Procedures should be followed. A Scrum Master or  Product Owner should work closely with the Project Management Office.
  • Stakeholder Management
    • Traditional: This responsibility falls onto the Project Manager via the stakeholder management plan.
    • Scrum: This responsibility is shared among by the Product Owner and Scrum Master. The Product Owner elicits requirements from stakeholders and the Scrum Master insulates the Delivery Team so they can focus on the product.
  • Communication Management
    • Traditional: This responsibility falls onto the Project Manager via the communication plan.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master. The Delivery Team meets daily and communicates progress and impediments. The Product Owner manages stakeholder expectations. The Scrum Master can assist with managing stakeholder expectations, facilitates the Daily Stand-up, Sprint Planning, The Sprint Review, The Sprint Retrospective, and coaches the principles of Agile to everyone in the organization.
  • Resource Management (formerly Human Resource Management)
    • Traditional: This responsibility falls onto the Project Manager via the Resource Management Plan.
    • Scrum: This responsibility falls onto the Delivery Team and Scrum Master via iterative planning sessions, capacity planning for each iteration, and relative estimation and using past performance to forecast velocity.
  • Risk Management
    • Traditional: This responsibility falls onto the Project Manager via the Risk Register, Risk Management Plan, and Contingency Reserves.
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner. The Delivery Team and Scrum Master use retrospectives to address risk and improve how they work. The Product Owner sets the guiding view into the future, sets the priorities for each iteration via the backlog, and makes informed decisions based on the technical expertise of the team and the strategy of the organization.

While the above is a high-level, “vanilla,” list of the shared responsibilities and activities, it illustrates my point. The Product Owner and Scrum Master are a lot like a Project Manager split into two roles. This allows them to share responsibilities and specialize in select areas — making them more effective and increasing the chances of success. As a coach, we need to make sure these two stand as a united front. The Product Owner steers the ship and the Scrum Master is the first-mate.

Leave your thoughts on Product Ownership, Scrum, or Project Management in a comment below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Improving Agile Retrospectives with SMART Goals

 

 

 

 

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, and Jaded Sage

| Jeremy Brien

Urban Legends and The Organization

I recently started binge watching a show called Supernatural. For those of you unfamiliar with Supernatural, it’s about two brothers, following in their father’s footsteps, traveling across mid-west America, solving mysteries of the paranormal. They’re a part of a small community of “hunters” who vanquish demons, ghosts, shape-shifters and other urban legends (great show! I highly recommend it!).

While watching S01E05, an episode based on the “bloody mary” urban legend, one of the brothers makes the statement, “all urban legends are based on some version of the truth.” This got me thinking about the urban legends that exist in our organizations and prompted me to reflect on when my own organization first adopted Agile to manage our projects.

“The seed of an urban legend find fertile soil at the corner of tragedy and imagination.”

― Thomm Quackenbush, We Shadows

Bad Advice: Ignore The Nay Sayers…

About a year and a half ago, I was one of the leading change agents in our IT Operations Section. I coached and taught Agile to our Server Group, Network Group, Desktop Support Team, Service Desk Agents, Database Administrators, a GIS team, and a Software Development team. Each team had one or more people labelled by management as the “naysayers.” I was warned to ignore them and push forward. However, I felt this was the wrong approach.

Naysayer or Jaded Sage?

I say embrace the naysayers. They are the organization’s seers. They have been around the block, seen past failures and experienced a variety of initiatives from different management regimes. They’ve lived through the failures of past projects. Over the course of their careers and their tenure, they have accumulated sage like experience. Unfortunately, the naysayers have become a bit jaded and skeptical of “initiatives” they’ve seen fail in the past. One might say they’re not quite ready to start “drinking from the kool-aid.”

Some of these urban legends sound like…

  • “They’ve tried this before…”
  • “Just another management fad…”
  • “Why are they trying to reinvent the wheel…”
  • “They’re asking us to do things outside our work performance standards…”
  • “They can’t throw this in the mix, we’re busy trying to keep the lights on…”
  • “They keep shifting priorities, we can’t keep up…”

Identify Project Risks With Respect and Empathy

Seeing repeated failure is frustrating. It’s only human to become frustrated and fear failure. Sometimes it sounds like the naysayers are full of “doom and gloom” but their urban legends really only spur from a place of fearful imagination. Because of their fear, there’s a certain level of “attitude” and defensiveness we may face we when first initiate a dialog with our jaded sages, however, treating them with respect, dignity, and lots of empathy will go a long way. This attitude will quickly dissipate and they’ll open up and impart some of their wisdom and lessons learned.

Our Goal Is To Identify Project Risks Early

Our goal is to identify project risks quickly and find that grain of truth in their urban legends. Their wisdom should never fall on deaf ears. As a coach, project manager, or product owner, it’s our duty to ensure our organization doesn’t miss out on opportunities to learn from past mistakes and to identify risks as early as possible so they are not realized, or at the very least, so risks can be mitigated and managed.

As a project manager, we can add these items to our risk management plan and start a qualitative analysis with the project team. Product owners and scrum teams can conduct a retrospective focused on the risks. Some of my favorites are:

  • The Sailboat – Use this technique to identify what things are helping the project, what is slowing the project down, and what risks are ahead (I like to draw a pirate ship and jagged rocks below the water line and differentiate between known risks and possible unknown risks for prioritization).
  • The 5 Whys – Use this technique to help identify root causes of known risks and get at the root of problems.
  • SWOT Analysis – Strengths, Weaknesses, Opportunities, and Threats. A classic technique usually used to form organizational strategy can easily be framed for risk identification. I like this one because “opportunities” can include good risk that we should plan for (example: We are planning an event for 200 people, however, what if 1000 people show up? This would be a good thing but jeopardize the success of the event if we don’t have a contingency plan to accommodate the extra 800 guests).

If you’d like to discuss more about managing risk and dealing with naysayers, I’d love to hear from you! Let’s connect and have a conversation.

 

Photo Credit: Flickr