The Top Five Hindrances for Project Managers and How to Overcome Them

Every year, the complexity of projects increases. The average requirements document is over 100 pages and changes 20 times during the development process. It’s brutal. That means as a Business Analyst or Project Manager, you likely spend hours circulating, editing and tracking changes to a hefty requirements document with the hope that your team actually stays engaged and orates it.

Wishful thinking, right? Here are the top five hindrances that are faced by Project Managers:

1. HINDRANCE: THE 11TH HOUR SWOOP - IN

An executive comes to you last minute with feedback that you needed three weeks ago.

Is it a must-have change or a nice-to-have change? Do you push the target? Do you immediately pushback to say, “Thanks, but we’ll get that into the following release?”

Maybe you go home after working late again and watch the movie “Office Space” for the 30th time to try to laugh it off so you don’t go postal on your boss the next day.

TIP: Be open

Solution:

• Give organization improved perceptibility and a continuous feedback loop to address matters before it’s too late. To be honest, we’ve (Management and Project Managers) been on both sides of this frustration. It’s unpleasant to be the swooper and the swoopee. The reality is that managers are busy dealing with a million diverse issues, and whether right or wrong, they will focus on what’s most critical.
• Also, thoughts come to management and other stakeholders after they see pilot product and realize what was stated in the initial requirements document a month ago isn’t the best solution now.
• So to avoid the 11th hour swoop-in, you have to be crystal clear and open for response/criticism at all phases of the project, and have fixed check-ins to get responses initially. If your crew and executive staff are in the similar office, this is easier to achieve. Have a whiteboard or dedicated wall in a prominent location sharing the latest designs.
• Every day, they’ll walk by and have an occasion to respond to what they see. Most people respond better to visuals vs written words to appreciate the user experience.
• If you’re a dispersed team in multiple locations, as is common today, then a dedicated tool that delivers everyone a central hub for the project’s requirements, linked designs and real-time feedback will help.
• They’ll see what’s happening as the project evolves no matter where they are, and you’ll be able to keep your finger on the pulse to hedge any disagreements or potential gotchas from happening later.
• But if at all, Business Analyst/Project Manager follows all the possible protocols to get everyone on same page and in spite of this efforts last minute changes arises, then he/she has to adhere to the changes and try to focus on that changes rather than complaining about it.

2. HINDRANCE: DECISION REHASHING

Hosting infinite conferences where half the time is wasted reassessing old decisions or bringing others up to speed. We’ll admit this one drives us crazy. We dislike meetings. But, we especially dislike meetings that are subjugated by repeating conclusions previously made. “Why did we choose to alter the functionality of that feature?” “When did we approve that?” “He was out last week, can we reconsider the plan so he’s up to speed?”

Painful, disorganised, annoying.

TIP: Be clear

• Deliver full framework of the judgements being made so everyone understands the scope of the project and why it is vital. People need simplicity and understanding to execute at their best.
• This applies upstream to your stakeholders and customers so they appreciate what they’re getting and it applies downstream to your designs, development and QA teams so they know precisely what to build and to test accurately.
• As a solution, new collaborative tools exist that will help you capture the healthy discussions and ongoing discussions that logically take place around requirements, and they don’t necessitate holding more meetings. People can add their feedback anytime and see what others are saying to agree or disagree, approve or reject, or propose edits to polish the solution.
• Also, the conclusions that occur in meetings aren’t easily outlined in documents and people’s memories diminish as time goes on. How many times have you left a meeting feeling great, thinking everyone is on the same page, only to find yourself debating what the team decided a few weeks later?
• If this is a concern for your organization, adopt a new practice like having a requirement document that would be accessible to everyone and updated by everyone which capture decisions in line with requirements, and make them easy for the team to view anytime. This will eradicate ambiguity and ensure that conclusions about the project are crystal clear.

3. HINDRANCE: CHANGE TAX

Manually sending updates to everyone when something changes kills a third of your day.

Anytime you’re doing something manually, ask yourself, “Can we automate this?” With today’s tools, often the answer is “yes.” In the case of executing complex projects, change is just something that’s going to happen. And, often for good reasons. As you get deeper into the design and development of a project, you know more than you did at the beginning. Thus, you and your team will think of better ways to build the anticipated product as you iterate upon the requirements along the way. If you try to manage versions by tracking changes in Word documents, then you’re going to experience a huge tax on your time. It’s nearly impossible to write the perfect requirements document the first time.

So stop believing that’s a goal.

TIP: Be iterative

Solution:

• Embrace changes judiciously by linking the dots, quickly assessing the impact and communicating the changes to the right people involved automatically.
• We can’t talk about requirements without talking about change. And we can’t talk about change without talking about being “agile.”
• The #1 reason to adopt agile within your organization is to create a culture that is dexterous so your team can respond quickly and effectively to changing requirements. Thus, iterating as you go.
• Don’t get hung up on the labels or the debate of whether Scrum vs. Kanban is superior. There is no definitive, one-size-fits all process. Agile first and foremost is a cultural mind-set, not a prescriptive development process.
• You want your entire organization to feel empowered to propose a change if they find a better solution. If you’re coming from a more old-fashioned Waterfall approach, your challenge with adopting agile is to avoid going from one extreme to the next.
• There is a myth that agile is about not having a plan and just building – which isn’t the case for most organizations. Smart agile teams maintain requirements best practices borrowed from traditional methods such as traceability, impact analysis and change management, so they can understand the ripple effect that a change has on the rest of the project. 
• It’s a balancing act between agility and prescribed control. Some call it a hybrid approach. Again, the labels don’t matter. The key is to find the mix of practices that works best for your team so you can execute projects without resistance. That’s what matters.

4. HINDRANCE: ATTENTION DEFICIT 

Creating a detailed 200-page plan that no one has time to read once, let alone every time a change occurs. You did it.

You just completed a month-long effort eliciting feedback from 50 stakeholders and writing the most beautiful requirements document of your life. From a CMMI or BABOK perspective, it is pure poetry of shall statements and use cases. Okay, enjoy that moment for about 30 seconds, because it will quickly be ever replaced with the fear of whether anyone will actually read it.

As project difficulty increases, how do you articulate what the plan is without creating a monster of a document? It’s tough. The issue might not be the length of the complete specification document. The issue is that you’re trying to communicate the entire plan to everyone using the document. In reality, most people only work on and care about specific parts of the plan at any given time.

When one item changes and you send a new version of the entire requirements document, it’s both information overload and white noise at the same time. We can’t expect people to hunt and peck for what changed and determine each time if it’s relevant to them or not.

This old way is incredibly inefficient, and people just stop paying attention.

TIP: Be relevant

Solution:

• Adopt the viewpoint that everyone identifies as everyone is simply too busy to absorb the entire document. Because literally, they are. To avoid being annoyed by your organization’s collective attention deficit, relevancy is key.
• This is an area where tools can help you break large, complex projects requirements into smaller controllable parts, and let people filter in on what’s relevant to them. We recommend you manage the scope of projects item by item to get work done. If you’re inquisitive what we mean by “item,” a requirement is an item. A use case is an item. A test case is an item. A flaw is an item.
• People naturally work on a list of a few items at a time. It’s how our brains work and we’re more productive that way. By listing the scope of your projects using a tool with a relational database, it will allow people to focus on specific items they are working on, while maintain context of the overall project.
• Then, as needed for baselines, releases or milestones, you can group together items and summarize the project via reports or a specification document for a holistic view.

5. HINDRANCE: MISMATCHED EXPECTATIONS

A stakeholder thinks he is getting X, Y & Z and is actually getting X, A & B. It feels like a blow in the gut. You and your team put your blood, sweat and tears into delivering a product only to learn after the launch that the end users aren’t happy.

What the heck happened? How did we miss the mark? Why is there an expectation gap?

TIP: Be proactive

Solution:

• People have choosy reminiscences. We all remember what we want to hear. What stakeholders forget is the auxiliary things they add along the way or the reprioritization of features as the scope changes over time.
• The X becomes X+1, and the Y becomes Y+2 and soon Z is out and instead the priority shifted to A and B, but not everyone was clear on the trade-offs that were made because the conclusion was made over the phone from a late night call with the customer.
• The intent was right, the team was being agile, but what was missing was the captured statement with the stakeholders documenting the demands, agreements and consents by the appropriate stakeholders.
• Next time, get buy-in on the priorities and capture the justification of what’s in and what’s out of a project, to ensure everyone has the same anticipations. Without adding a lot of needless overhead, new tools offer the capability to capture the reviews, approvals and electronic signatures for scope changes as part of the natural workflow.
• That way everyone can feel confident they know the true plan and the team can feel good about delivering what’s assured. You deserve to have the launch event be a celebration not an interrogation of what went wrong.

These hindrances are faced by each and every Project Manager, so it is very necessary that he should be able to tackle difficulties arising due to change in requirement, mismatch expectations of client and project manager and last minutes changes on the product during the software product development.

About Author:

Varun Shimoga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: varun.shimoga@spluspl.com