Being a program manager at the oldest bank in America for the past decade has given me insights that I would not have otherwise understood fully. I’m Diana Henderson Webster and I have been some form of PM since 1998. I’ve done it all, seen it all, fallen for it, stumbled over it, raised it up and closed it out. I love to share in hopes that others will not stumble and fall over the same things that I did. Or if you do, you take the lesson to heart and better know what to do next. I do see success as getting back up. Growing and becoming successful is formed from equal parts “what was learned “ and “what was accomplished”. A PM (Waterfall, PMP, Scrum Masters and Product Owners) has a front row seat to it all.
Asking questions is the number one action anyone can take to solutioning any challenge or issue. Effective use of questions doesn’t stop with the words coming from your fingertips or out of your mouth though. It is the listening and hearing the answer too.
Setting expectations is the number two action anyone can take to solutioning any challenge or issue. The beginning of setting expectations is not the communication but listening and hearing what is to be done.
Clear communication is the number three action you can take to have project success.
Ask the questions, hear the answer, write down the down answers to validate. Even if you are joining a project team mid-stream, the answers to this fundamental list of questions are valuable to you and to stakeholders.
Experience teaches more than can be written in a blog (or even a series of blogs). In one of my recent newly acquired projects, I became dismayed at how often I was hearing “what does that mean?”. From project tasks to evidentiary success criteria, team members were confused. We are not talking about new team members. We are talking about individuals who are considered stakeholders and had been involved for nine months prior. Obviously, the handoff was not seamless, and it created extra action items, extra meetings, and all-around extra work. The impact on the team’s morale was palatable. We continue to work thru the crisis. I’ve added risks to program documentation. The action of documenting risks and the mitigation plan are part of the clear communication mentioned above.
AgileDad provides many aide’s for your reference on this topic and others. Some of the below are referenced in the Agile 12 Steps document. I’ve taken liberties with similar language commonly used in corporate hybrid environments. Below are some fundamentals that will help. Let’s start at the top, shall we?
Projects - A project has a defined start and a defined finish. It is part of a Program, which is part of a portfolio. Once a task has reached the point where it is part of a process or procedure for Operations to incorporate in their everyday world, it is no longer a part of a project, it is Business as Usual (BAU). This is a concept that is universally understood by PM’s, but not necessarily by other leaders at a company. This is something that must stay top of mind in every step of the Agile methodology.
Define the problem - If you have a project, you are working to resolve a problem of some sort. Take the time to make sure that everyone involved understands the problem and the method you have chosen to resolve. We are assuming that Agile is chosen for our purposes.
Establish or Define the Vision - At the outset, defining what success looks like is crucial to success. Where we are going and who is getting us there are elements that can not be lost. The North Star should not change very often. Honestly, I have suppressed many an eye-roll over the years over this. Time and again, I’ve heard a leader asks “what does success look like” mid-stream in a project. In fact, the leader should be saying “success looks like X, Y, Z, as per our charter.” In large corporations’ ownership gets sticky between all the moving parts. The charter should give the overall vision and referred to proactively along the way by the Scrum Master and Product Owners.
Roles - Defining who is doing what up front is important to keep the process moving forward. We no longer are in the Wild West. Sometimes it feels as such when Stakeholders and Team Members overstep their role. The bigger the teams, the more projects within a program and portfolio, the harder it is to manage this. Some, who are in the Waterfall mindset, prefer the RACI. If you have a mixed or hybrid team, perhaps the RACI is best for you. The RACI stands for a chart that defines who and what on any given category of task. Responsible, Accountable, Consulted and Informed. As a heads up, this is always a controversial conversation. Inevitability, one party or another do not believe they should be responsible or accountable for…something… be prepared. This may be more important to the stakeholders than your scrum team. POBAFATA and SM will likely be crystal clear on their role. (Listen to the POBAFATA podcast to learn more)
Backlog Preparation - Having the backlog established at the outset is an important step to defining success and managing scope. Using the INVEST model will help in preparing for planning. If this isn’t done, the alternative is chaos and lesser results. Groom your backlog. Prioritize enhancements. The results will be incredible.
Testing - Who and what will be tested in what manner is important to document. Explain the decisions up front too. If addressing business process and software, this can be a bigger challenge than you would think. Recently, I worked on a program where both business process and technology are being built. Assumptions around testing were faulty. The effort in fixing this is huge and a distraction.
Communication Plan/Meetings - Establish this early to set expectations of your team and other stakeholders. Meetings are the number one distractor from actual work. Ineffective meetings are the death of a program. Every single meeting should have a documented purpose and agenda. Every single meeting should produce a recap. If you don’t have a purpose and agenda, cancel the meeting. If you are invited to a meeting without those things: ask for them. Want to hear more tips and tricks for great, effective meetings? Here is a podcast for you: Top 10 tricks to making your meetings better!
Until next time, dear reader, remember our Agile Manifesto It is concise, yet broad. It is a concept, yet actionable. Keep it top of mind as you wade thru the Agile Way.
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
· Individuals and interactions over processes and tools
· Working software over comprehensive documentation
· Customer collaboration over contract negotiation
· Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Comments