Project Management Blogs

The close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
   1. Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
   2. Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
   3. PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.
2. Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

   In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

3. PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.

   The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

4. The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
   1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
   2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
   3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.
5. BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
   1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
   2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
   3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.
6. The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
   1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
   2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
   3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.
7.  “The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools. 

 Don't forget to leave your comments below.

Elizabeth and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition. 

In many organizations, project managers are the Rodney Dangerfields – they don’t get no respect!  We regularly experience the tug-of-war relationship between project and functional managers, but the same challenges often occur between project managers and their team members.

Issues with this dynamic frequently stem from confusion related to their respective roles, but they can also be caused by a lack of understanding of basic rights and responsibilities.

While these should all be common sense, to try to address this root cause, a review of some “generic” project manager rights and responsibilities may help. 

Responsibilities:

• Help team members understand the vision and objectives for the project and how its outcomes could benefit the organization and them.
• Define objective expectations for a team member about how status updates, issues and risks will be communicated.
• Walk team members through key project management artifacts covering scope and schedule so they can better understand how their work products fit in to the overall delivery of the project.
• Actively engage team members in the project by involving them in scope definition, activity effort estimation, risk identification and analysis and any other appropriate planning (and re-planning) activities.
• Challenge (or remove) unnecessary administrative hurdles from the path of team members to help them be as productive as possible
• Provide regular, objective performance feedback for the team members to their functional managers
• Regularly update team members on overall project status including expected outcomes and any approved changes to project objectives or constraints
• Review the role of the project manager with team members so that they understand what is and is not “in scope”

Rights:

• Team members should keep the project manager apprised of changes to their availability
• As per the defined and communicated expectations, team members should provide the project manager with progress updates, and any other information that is key to successfully managing the project including identified changes to issues, risks or scope
• If the team member has concerns or confusion about their assigned work, they should communicate this to the project manager and get their assistance to resolve these in a timely fashion
• If part of the team member’s role is to disseminate project information to their functional area, they should do this and not hoard knowledge
• If the team member has an issue with another individual on the project team, they should first attempt to resolve the conflict directly with that team member, and if that does not work, they should engage the project manager to assist

As Josiah Stamp put it best “It is easy to dodge our responsibilities, but we cannot dodge the consequences of dodging our responsibilities.”

Don't forget to leave your comments below.

As we start off the New Year, it often takes a while to get back into the swing of things.  Thus, project results can become delayed or dampened while ramping back up to speed.  Instead, in today’s new normal business environment, where sales are lackluster and cash is tight yet service is paramount, there isn’t a moment to lose on achieving critical project results. 

One of the best ways to accelerate project results is to orchestrate a small, quick win.  A quick win gives the project team a reason to celebrate success and become re-energized on the project objectives.  It reminds the team of where they left off, why the project is important to the executives and company objectives, and it gives the team members a way to kick off the New Year with recognition.

Undoubtedly, there are countless quick win possibilities for every project team yet achieving them when you need them can be a challenge.  So, what are a few tips to ensure your project team achieves a quick win?  1) Reengage.  2) Ask Questions.  3) Pick a “win”.

1. Re-engage:  First, you must reengage your project team!  Don’t expect your team to continue where they left off.  Even if they wanted to do this, there have likely been too many distractions over the holidays.  Instead, kick off the New Year by bringing your team together. Reengage with them.  Back up for a few minutes and discuss why the project is valuable.  Recognize each team member for their part of the project success thus far or their key role in the project.  Remind the team of the critical path and where they left off.  And last but not least, reengage as the project leader.
2. Ask Questions:  It’s surprising how simple it is to ask questions yet this secret to success is often overlooked.  First, find out where you project team stands.  Ask them what they think is most important to ensure success?  Is timing critical?  Resources?  Overlap with other departments or external resources?  Encourage debate and brainstorming.
   Find out which are the most critical upcoming tasks. Why? Is everyone on the same page? If not, why not? Should we incorporate any tweaks given the progress so far?  Ask about potential roadblocks. Listen carefully.
3. Pick a “win”:  Choose a small, quick win as a project team.  Most importantly, ensure everyone is on the same page.  Ensure everyone has an opportunity for input and feedback. 

Then, develop or clarify a plan to achieve the quick win.  Make sure the leader of each project task understands its importance.  Communicate in advance that a critical path task is coming up.  Encourage teamwork.  Do not dictate; instead, participate. 

Plan to celebrate the win.  Begin promoting the importance of the quick win immediately to key stakeholders and executives.  Your #1 job as project leader is to ensure the quick win is perceived as a quick win!

The power of a small, quick win is incredible – there’s nothing like it to gain momentum.  It isn't complex, expensive or time consuming yet it can propel your project forward in the New Year.  Why not reengage your project team to plan a quick win immediately?

Don't forget to leave your comments below.

As an agile coach, one of my favorite expressions in response to nearly any situation I encounter in an agile team is—“trust the team” or “trust the process”. So here are a few examples of what I mean:

If you think the team has underestimated their work and are leaving velocity on the table, “trust the team”…

-          If they have underestimated they can always pull in more work. And you know, you could be wrong, so allow the team to sort through how they understand, size, and execute their work. They’ll appreciate the trust you’ve given them and will invest in doing good work.

-          If you do see poor estimation or poor execution & adjustment, then bring this to the attention of the team within their retrospective. Give them examples, but allow them to explore the most effective way(s) to improve.

If you feel that the team isn’t working hard enough or are committed enough to their work, “trust the team”…

-          Unless you’re a direct member of the team, it’s fairly presumptuous of you to assume they’re sand-bagging and not working hard. Or thinking that they lack commitment. Rather observe how hard they do work, handle their challenges, and deliver on their sprint commitments. Assume that the wonderful professionals you’ve hired are just that—hardworking, honest, and professional.

-          And remember, just because people are putting in hours, that doesn’t mean they’re doing good work or working hard. It just means you have their butt in their seat…not their brain in the game.

If you feel that quality is poor and it isn’t improving sufficiently or you feel that the team isn’t taking product quality seriously, “trust the team”

-          Ensure that your concerns are visible to the team and that they’re looking into root cause within their retrospectives.  However, let them tailor their activities to improve deliverables each and every sprint. Explore objective data on their defect & quality deliverable trending with them. Give them clear and complete done-ness criteria. BUT, allow them to discover how to do a good job as a team.

-          Agile is not a magic formula. It cannot take a crappy product and, simply because you’re ‘agile’, remove all technical debt and bugs overnight. Improvement takes serious effort, commitment, and time. No silver bullets allowed!

If you’ve got a fixed date software delivery to make and you wonder if the team is going to get there, “trust the team” and “trust the process”

-          First of all, solid agile teams make everything transparent. Secondly, they approach delivery in iterative chunks. Put these two together and you’ll actually get a heartbeat of how well the team is meeting your projections & needs. If they aren’t, then you get the chance to negotiate scope trade-offs with them.

-          Agile projects can ALWAYS hit fixed date targets with fixed cost & quality goals. And they can ALWAYS deliver a set of your highest priority features. The variable in these situations though is scope—so you must be prepared to pare back scope via dropping low priority features and making micro-adjustments to other features—generally delivering Must-Haves over Nice to Haves.

If you feel that the Product Owner isn’t making good decisions surrounding feature priority, “trust the process”

-          The Product Owner will get plenty of feedback in the Sprint Reviews as to whether they’re focusing the team on the ‘right’ features, at the ‘right’ time within the flow of the project. The key is to get stakeholders regularly attending and to encourage positive and constructive feedback.

-          Quite often the Product Owner is a surrogate without real decision-making authority. That is NOT setting them up for success. Ensure your Product Owners are empowered to make decisions and have the seasoning and domain experience—to make the ‘right’ decisions.

These are only a few of the many real-world situations where we have a choice in how we actively demonstrate our understanding of agile principles and exhibit trust to our teams. You see, it’s not about saying you trust the team—it’s about truly trusting them and demonstrating that in in your words and actions. Next I want to explore a few, how shall I say it, trust anti-patterns or excuses that I commonly see.

There’s trust, and then there’s TRUST

Here are a few anti-patterns I frequently hear that indicate to me that the organization, leadership, project, management and other stakeholders don’t fully trust the team. I’m sharing them to broaden your thinking around trust and the ways we can frame it organizationally. By no means is this an exhaustive list, but more so a list that illustrates how our words don’t always necessarily align with truly trusting.

And of course this doesn’t apply to anyone reading this blog. So please just read it for future reference—in case you run into some of these anti-patterns…

Trust, but Verify

Of course I trust you, but I’m just simply verifying that what you’re telling me is true—as a simply checkpoint. Don’t worry about it, I’m just verifying…

Don’t be fooled, this anti-pattern isn’t about verification. It’s about distrust and the use of micro-management techniques to get into the heads of the team and control how they’re attacking the project. Yes, verification is important, but not daily. The Sprint Review is the ultimate verifier. Attend them.

The process is making me do it

Of course I trust you, but I need to get this information into the CMMI Level 3 artifact repository so that we pass our audits. Did you know that an audit was coming next month? Very serious stuff…

Another common anti-pattern is blaming distrust on the methods or process patterns that you’ve adopted as an organization. We’re CMMi Level 4, so I must have you fill out a detailed test results plan and sign at the bottom to confirm that you’ve tested everything you’ve said you’ve tested.  

Sure, processes carry some weight and responsibility. But this anti-pattern extends that as an excuse to hover over the team and control approaches & outcomes.

I’ve been doing this a long time and I know this path will lead to a disaster

Of course I trust you, but in my 25 years of experience, I’ve never seen a team deliver on a large scale refactoring effort. I simply don’t think it can be done…

While your experience is certainly valuable, times have changed and contexts are different now. Your team is exploring their own experience and finding their way. They’re establishing their experiences, and need to do that largely on their own…as you probably did.

I’m paid to prevent us from making mistakes

Of course I trust you, but my job is to prevent us from making mistakes and to develop the best products possible. It’s actually in my job description that I lead the team by the sheer force of my will and experience.

That I’m responsible and accountable for all of the results my teams produce. That leadership is about leading—showing team the way forward in practices and approaches. Trust does come into play, and of course I trust you, but only so far. Only when I have a belief that the outcomes will align with our organizational goals and my bonus plans.

True Trust

I have a favorite story I use for describing effective delegation. It goes like this—

Delegating is easy when you know how someone will approach the problem you’re delegating. Or when they’ve been asked to do the task many times before? There is no outcome risk.

But what if they would approach the solution differently than you? Or what if they might try a novel, but risky approach? Or, what if you’ve seen them fail at this sort of problem many times before? You ‘get’ the idea…but you still delegate to them. To me, this delegation, regardless of outcome risk, or approach, is true & pure delegation.

It means you trust the individual enough to encourage them to try something new. You’re enabling their creativity and you’ll be there if they ask for your help or advice. But they ‘own’ the task you’ve delegated to them and ultimately the results.

Now THAT’S delegation!

Adapt this definition and re-focus it towards trust. Then accordingly, start trusting your teams more. For example, here are a few transitional trust adjustments you might need to make—

• Trust that they are estimating work based on the best information they have—and that the estimates are accurate given their context
• Trust that when they run into trouble, they’ll let you know; otherwise they are making progress and don’t need your ‘help’
• Trust that transparency and Sprint Demo’s will give you sufficient progress information—both on velocity and quality of their efforts
• Trust that the team knows best in how to solve product development challenges related to architecture, design, and implementation
• Trust that your Product Owner is effectively driving customer value—and are making the best decisions balancing business needs against team capacity
• Trust that your Scrum Master is emphasizing done-ness, quality, and working collaboratively as a team. That if something needs attention, they’ll raise it as an impediment
• Trust that when the team recommends refactoring a component of your system—that it’s truly broken and needs attention
• Trust them to trust your own judgment and skills; that they look to you for high level guidance, goal-setting, support, and impediment resolution. 

Wrapping Up

True trust, like delegation, can be really hard. As leaders, many of us have engineering backgrounds and are natural problem solvers—so our efforts to engage the team with our ‘advice’ emerges from our own backgrounds, skills, and interests.

We’ve also been programmed not to trust our teams. The inherent dynamics of Taylorism and Scientific Management influences our behaviors when it comes to telling our teams what to do and hovering over them until they do it.

But trust is what a truly empowered and self-directed team needs from you. Of course you can inquire measure, establish vision and set goals, measure results, and provide feedback. Surely you’ve earned that right with your experience and role. However, try and give true trust as often as you can. You’ll see a huge difference in your teams’ performance and the results.

Thanks for listening,

Bob.

Don't forget to leave your comments below.

What is one of the root causes of project failure?

Last month we explored how much project management was enough.  It is generally accepted that just the right amount is needed based on the situation.  It is usually when the project is over or under managed that we have failures.  Common project management causes of failure are:

• “Wishful” Planning – Planning that is based on the desire to have something done by a deadline and within a budget limit without regard to the reality of the situation.
• Lack of portfolio management – initiating projects without regard to whether they are justified based on sound business reasons
• Poor project control communication – Hiding the reality of project trouble until it is too late to do anything but bemoan a horrible outcome
• Lack of accountability – Allowing project stakeholders to fail to deliver what is expected of them without accountability.
• Absentee sponsors – Sponsors failing to perform their functions to provide direction and leverage.

Each of these causes is worthy of an article if not a book.  But, in this article, let’s look for a common root cause. 

In a recent webinar, Joseph Grenny hypothesized that the root cause underlying these and other problems in projects is failure to effectively hold crucial conversations.  It is the Abilene Paradox in action, where silence or avoiding difficult confrontations robs the project team and its organization of the ability to either avoid the causes of failures or to catch the causes early in their life to turn the project around or end it when that is appropriate.

What is the Abilene Paradox, you might be wondering?  It is the phenomena where a group of people collectively decide to do something that is counter to the preferences of everyone in the group and counter to the benefits of the organization or group as a whole.  It involves a breakdown in communications.  Each member of the group avoids saying what they think because they think it would be counter to what the group or its leadership prefers.  As a result valuable information is withheld and the group is not able to make effective decisions.

For example, an individual feels that a project plan is overly aggressive but fails to speak up because he or she is afraid that saying anything about it would have negative consequences.  As a result the “wishful” plan becomes the baseline plan and sets expectations for the project.  This leads to the inevitable overruns and the rushing, corner cutting and such that, in turn, causes poor quality product to be delivered late and over budget.

If, fact, this failure to speak up and hold the crucial conversation in a respectful and candid way is a root cause of these causes of project failure, what can we do about it?

If we are in a position of influence we can create a safe environment in which people do not feel threatened for saying what they think, even if it is not what everyone wants to hear.   If we are a less influential (everyone has some influence, usually more than they think they have) player, we can muster up the courage to “tell it as we see it” and learn the skills of how to confront directly and firmly with appropriate diplomacy.

Don't forget to leave your comments below.