“Practice Innovations” is a quarterly, online newsletter that examines best practices and innovations in law firm information and knowledge management. In this installment, the author talks to three knowledge management leaders about recent innovative projects within their firms.
Utilizing project management methods is the best way to deliver a desired project outcome. A very good way to learn the framework for project management is to manage a project. During the 2018 AALL PLLIP Summit, three panelists shared their experiences in “From Start to Finish: Getting their Project Management Game On.” This article summarizes their thoughts.
We spoke to:
- Sandra Dunbar, Firm Librarian at Heyl, Royster, Voelker & Allen, about the Boy Scouts of America’s Requirement 9 and project plan requirements for an office/library move.
- Katherine Lowry, Director of Practice Services at Baker Hostetler, about Agile methodology, target marketing, and projects using predictive analytics.
- Megan Von Behren, Senior Research Services Manager at Fried, Frank, Harris, Shriver & Jacobson, about Waterfall methodology and her Request Tracking System.
Elaine Egan: Sandy, your project involved a firm move, what was it that drew you to the Boy Scouts of America project plan requirements and why was it an idea for planning a library move?
Sandra Dunbar: I had limited formal education in project planning, but plenty of volunteer experience. As a merit badge counselor, I taught the Personal Management Merit Badge to quite a few Boy Scouts. Requirement 9 requires the preparation of a written project plan, including goals, process, timeline, and desired outcomes. I had applied these principles, learned from the Boy Scouts of America, to other volunteer experiences, as well as to scouting activities — Cub Scout Day Camp Program Director, Volunteer Food Coordinator at Spider Hill (a joint effort of a local park and the Chillicothe Optimist Club), annual toy drive coordinator for the Optimist Club. Each of these activities required advanced planning to carry them off efficiently and effectively.
The planning steps are simple but provide the necessary framework to accomplish the task. At the same time, there is flexibility to adjust according to the needs of the project at hand. As a counselor, I allowed the boys to develop the plan. The book offers suggestions as to how each step might be accomplished. I encouraged the use of lists and excel spreadsheets based on the age and skill level of the youth. And those were the tools that I incorporated for our project — spreadsheets lend themselves to timelines, resource lists, and budgets.
Elaine Egan: Katherine, Agile project management is an iterative methodology and is often an approach in software development and improvement. How did the Agile framework influence your project success, and do you practice Agile generally within your organization?
Katherine Lowry: Yes, within the past two years, we adopted Agile methodology more formally in our Project Management Office. Not every project is a good fit for Agile, and as such, we use Waterfall for things like software upgrades or moving on-premises solutions to the cloud. Agile is most often used in innovation projects where iterations, called sprints, determine the period of time in which a set of work must be completed and ready for review. These sprints allow us to release improvements more rapidly to the business.
“The planning steps are simple but provide the necessary framework to accomplish the task. At the same time, there is flexibility to adjust according to the needs of the project at hand.”
— Sandra Dunbar
Elaine Egan: Megan, deploying a Research Intake System involves both technology and change management. Can you describe the linear approach of Waterfall and the benefits or disadvantages it offers for this complex project?
Megan Von Behren: At the time I began my project, I had no prior formal project management training, so I wasn’t conscious of actively “choosing” the Waterfall approach for any particular reason. So, it’s tough to speak to whether it had advantages or disadvantages.
Even from a post-game perspective, I don’t consider myself familiar enough with the other approaches to say whether one method would have worked better than another. The pro-Agile literature seems to imply that in the Waterfall method, one cannot return to any previous steps, or move forward until previous steps are completed, and that changes to requirements are difficult. But I don’t believe this is so, and it certainly wasn’t impossible in my project to change requirements (although definitely difficult, which probably owed more to my lack of experience than to any choice of approach).
Traditional project management emphasizes monitoring and controlling, performing integrated change control as needed, then monitoring and controlling again. Execute, make a change, update your plans, execute again. Wash, rinse, repeat. Many of the requirements of my project changed subtly throughout the process, and one massive change revised the deliverables for the project significantly. But never did we have to go all the way back to the drawing board entirely to incorporate even major changes.
I think perhaps Waterfall has developed a reputation for being static and inflexible, but it’s important to keep in mind that “Waterfall” is more of a metaphor for thinking about what the steps are in a theoretical project. In fact, some refer to it as a framework rather than a method. The steps are meant to be iterative, not linear. Real life does not happen in a linear fashion, so it would be unrealistic for us to expect that any real world tasks could truly follow such a strictly structured plan. The concept of a waterfall, with activities flowing down from step to step in a linear fashion, like water flowing down across stones from a high ridge, is really more of a way of identifying the discrete steps than an actual map to follow.
That said, when I began my project, I wasn’t even aware of what these discrete steps were, let alone aware of a way that my project could have been managed better. Had I been aware of what “integrative change control” was, and the fact that it’s a normal part of a project, it might have saved me from the panic attack I experienced when my significant requirement change came around the bend. Had I been aware of some of the basic building blocks of project management, such as the project plan, scope, risk assessment, and stakeholder management plans, just to name a few, I might have headed my significant requirement change off at the pass, at the top of the waterfall.
The “choice” of the Waterfall approach isn’t what lent my project advantages or disadvantages, but my lack of knowledge of any method at all is what tried to sink my project, like a rock in a stream, headed towards a waterfall.
So, to answer your question, I believe you can view the Waterfall method as a way of knowing the basics of project management rather than an actual approach. At the time of this particular project, I did not know the basics, which did create disadvantages.
Elaine Egan: Katherine, in so far as Agile is iterative and a team-based approach, were there any challenges in applying the team approach to tasks and time schedules? Additionally, how did you assign a project team, and did Agile contribute to the development of the team?
Katherine Lowry: Challenges faced were an understanding of the methodology contrasting that of the in-grained Waterfall approach. User stories were familiar to us but Agile forces you to think about the product roadmap, ultimately revealing how the user will make use of the product. This aids the entire team — from developers to subject matter experts — in delivering on that vision.
The make-up of a team is different in Agile, specifically with the selection of a scrum master and a product owner; however, the business sponsor, developers, and subject matter experts were common to us under the Waterfall approach.
It was important to us to define these two roles in order to follow the Agile methodology: scrum master and product owner. Scrum master is the team lead and is responsible for facilitating the team and helps in advancing the project even when issues arise. The product owner leads the vision of what is to be built.
Elaine Egan: Megan, in identifying project pitfalls what were the tools in the Waterfall method that reduced conflict or lack of clarity around the initial requirements?
Megan Von Behren: The tools one should use to reduce lack of clarity around initial requirements are, in a nutshell, all the planning documents one should create at the outset of a project, namely, a project plan (which includes scope, requirements, plans for managing schedule, budget, quality control, human resources, communications, risks, procurement, stakeholders, and change management.) Tools assessing stakeholders, stakeholder requirements, risks, and contingency plans also are crucial.
Will these tools reduce conflict? That’s debatable. Tools exist to identify all potential stakeholders and analyze their power and influence over your project, as well as their interest in, and impact on, your project. Based on your analysis, you can determine if you need to keep your stakeholders satisfied, manage them closely, monitor them, or simply keep them informed. Registers are ideal tools for keeping track of stakeholders and their stats and can also serve as maps for where the stakeholders are now in relation to your project versus where you want them to be. Are they unaware of your project, and would you like them to stay that way? Are they resistant to your project, and would you like to move them towards neutral or supportive? Or are they your champion, and do you want to keep them happy at all costs?
“Tools exist to identify all potential stakeholders and analyze their power and influence over your project, as well as their interest in, and impact on, your project.”
— Megan Von Behren
There are numerous publicly available charts and tables you can use to collect this information; that part is straightforward enough. What you do with it is something they didn’t teach me in Project Management Professional (PMP) school. When I began my request tracking software implementation project, I didn’t know project management from a hole in the wall. But I do have common sense, willpower, and stick-to-itiveness, which I used to barrel on through and force my will upon the people I worked with. I think my co-workers still like me, or at least tolerate me, but I certainly did not win any new friends.
The beauty of planning ahead to see who might need or want what in a project is, first and foremost, so you’re prepared and not caught off guard. But the side effect of strategically managing your stakeholders is finesse, diplomacy, morale, and the maintenance of good relations. It is guaranteed that you will need your co-workers in the future, and yes, even your vendors, so it’s imperative that you don’t burn bridges. Giving your stakeholders a chance to voice their input, act according to a clear schedule that has been adequately communicated to them, and participate in a calm manner — not akin to chickens running around with their heads cut off — is invaluable.
You manage your stakeholders so you don’t annoy them, so they will be willing to help you when the next project comes knocking. You can use the tools, but you also need people skills, and that is the topic of a different article. Hint: I’m not above bribing people with cookies!
Elaine Egan: Sandy, what are the formal mechanics or tasks required in the Boy Scout merit badge for advanced project planning?
Sandra Dunbar: Requirement 9 of the Personal Management Merit Badge has the following steps:
- Define the project. What is your goal?
- Develop a timeline for your project that shows the steps you must take from beginning to completion (a spreadsheet works great for this).
- Describe your project (also a spreadsheet).
- Develop a list of resources and identify how these resources will help you achieve your goal (spreadsheet again).
- Develop a budget for your project (not needed for the office move, as the facilities coordinator managed that, but I would use a spreadsheet).
Elaine Egan: Katherine, how did you go about formalizing your project plan, such as a charter and sponsorship? How did your various relationships within organizational groups such as IT influence the project outcome?
Katherine Lowry: Our formal Project Management Office instituted governance and protocols well before adopting Agile methodology. First, a project idea must be submitted. This document is generally the starting point for the Project Charter, but it is used early to present to the Information Systems (IS) Steering Committee, which oversees the entire portfolio of projects and governs which projects move forward versus those that are dismissed. The targeted marketing project using predictive analytics was an idea presented to us by a partner, so we executed the project idea with the partner as a sponsor.
Various groups across the organization were tapped to ensure a successful completion of this project. I served as a scrum master. The partner was heavily involved and served as the product owner. Nicole Snyder, Legal Researcher and a member of the American Association of Law Libraries (AALL), was a subject matter expert and helped us to pull more than 18,000 patents. She served as a key contributor to our success by working with our developer on understanding the data. Patrick Flanagan, Legal Researcher and another AALL member, helped to classify the data in order for our developer to build a predictive algorithm.
Elaine Egan: Sandy, looking back at your project, was there anything you would have done differently?
Sandra Dunbar: I had no choice but downsize the library, the physical footprint was larger, but the shelf space was reduced. In hindsight, I should have reduced the collection further. I also regret not making an effort to keep track of actual time involved in this project.
Elaine Egan: Katherine, there are many ways a project can fail and scope-creep can influence every level of the project. Did you negotiate from the original specifications of the project in order to avoid project failure?
Katherine Lowry: Constantly! Many ideas surfaced on how to build this solution, but with assurance that we would address the additional variables in future phases, we narrowed the scope to an achievable project. The key really was making it visible using a Kanban board to show that we captured the idea and held strong on delivering on the first phase before engaging on additional ideas.
Elaine Egan: Megan, did you find the more stakeholders you had, the more complex the project, particularly as it relates to change management? What did a project management approach do to help alleviate barriers?
Megan Von Behren: Fortunately, my particular project (a request tracking system for our IS Help Desk and Library) was not attorney-facing, which drastically reduced the number, power, and influence of my stakeholders. My stakeholders were the IS Department and the Library staff. The impact my stakeholders had on my project, and their interest in my project, was high, but since our IS Department only has 59 members globally, many of whom could be grouped together in terms of requirements, there were not that many that needed to be managed. And most of their requirements were not competing. So, no, the number of stakeholders did not create complexity for me in terms of change management.
“Communication is key! All members of the team were highly collaborative and much of it was thanks to the project methodology.”
— Katherine Lowry
What did contribute to complexity in change management is the fact that I did not do any requirements gathering from the majority of my stakeholders, nor did I do any kind of risk assessment, change management plan, or contingency planning. Here’s how it all went down.
At the time my project commenced, my firm had only the bare bones outline of a project management process, mainly consisting of formalizing the description of a project using a template we call the Project Initiation Document, or PID. So, my team and I wrote a PID, and then started work choosing a vendor and beginning the procurement process, simultaneously, while waiting for approval of the PID by our Global Director of IT. Once the Global Director signed our vendor contracts, we held a kick-off meeting, and then began holding weekly design meetings, which lasted several weeks, generally adhering to a schedule formulated by our implementation consultant. During this time, we farmed out work to internal resources for connectivity and mapping issues, according to plan. Once the design was complete, we created and implemented formal testing, among the project team and by selected members of the IS Department across functional areas. Testing was followed by repair and correction of issues uncovered during the testing.
Once that was completed, we began preparations for going live. At that point, we detected a critical security issue. We convened numerous meetings to determine the scope of the problem and attempted to create workaround plans. However, approval of the workarounds, procurement of third-party software, and testing of the third-party software took several months. Once we implemented the fix, we had to complete the testing process and go-live prep again, and then we finally launched, several months behind schedule. Had we known to create a stakeholder plan at the outset, we might have been more aware of our stakeholder’s security requirements. We could have incorporated the need for the third-party software into the original plan, and more accurately predicted resource needs, budget, and launch date.
What we also sorely needed at the outset was a risk management plan. Before initiating, I had no sense of what the risks might be, much less a plan in place to mitigate them should they come to pass. Thus, I was blindsided by the security risk we encountered, and with no ideas how to move forward, we were dead in the water for a few months until we could mobilize. I also had no pre-set methodology for how to turn the ship when we ran into trouble. I now know that in the future, engaging my stakeholders more frequently will give me lots of eyes to spot these types of risks.
Elaine Egan: Katherine, Agile at its best creates opportunities. What is it that improved the quality of your project outcome?
Katherine Lowry: Quality hinged on two things: process and people. The team assembled was small but powerful. Selecting the right team depends on having the right expertise, whether that be subject matter experts or technical skills. Using Agile methodology helped us streamline the process and achieve success in four months.
Elaine Egan: Megan, Sandy and Katherine, if there is one take away from your selection of your project methodology what would it be?
Katherine Lowry: Communication is key! All members of the team were highly collaborative and much of it was thanks to the project methodology. Using a Kanban board was a great communication tool for the partner to see and visualize the project, understand the obstacles, and keep us on task.
Megan Von Behren: Again, I can’t say that I selected a methodology — in this case, a methodology selected me. Or, more accurately, I used no methodology whatsoever, which nearly derailed my project.
Learning a methodology via my PMP boot camp certification class taught me where I went wrong and how I could have avoided my pitfalls. Lastly, I know that Waterfall is sometimes referred to in the industry as a method, and is commonly thought of as linear, but it’s important to keep in mind that Waterfall is iterative, and it requires lots of simultaneous steps and circling back. Instead of Waterfall, let’s call it the Eddying Brook method. Regardless of what methodology I chose (or didn’t choose, as the case may be), or what I choose to call it, my takeaway is: Know Thy Stakeholders, Know Thy Risks. That, and bribe people with cookies to get them to do what you want.
Sandra Dunbar: Use your plan to keep the project simple. Don’t make the project more complicated than it has to be. There should be a logical, practical reason for every step and each thing that will be done.