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
