I once had a project manager (PM) on the client team ask me why I was capturing such detailed notes in a requirements meeting.
That question took me by complete surprise.
After all, my role was not to capture requirements, conduct any business analysis, or architect any solutions…or was it?
Many think that the primary roles of a project manager are to:
And all of these are correct pieces of the job. However, how a technology project manager does their job makes all the difference.
The first principle in technology project management is to engage in active listening.
Too often, we see technology resources immediately designing the solution in a client's mind before they listen to all of the requirements.
If the project manager has some experience with the final deliverable platform, it will be much easier to "listen between the lines" as the client is expressing the desired future state scope that you're supposed to be monitoring.
The second principle is understanding. This can be the tricky part, and it directly relates to active listening.
The project team is typically on the hook to deliver some kind of information back to the client. The deliverable should express a level of understanding regarding the client's desired result — i.e., a specification document, process diagrams, or a list of user stories.
No matter the method, translating the client's request into a digestible format that clearly expresses the scope is paramount.
As a project manager, the last thing you want is rework or scope creep.
Make sure you are willing to stand firm against clients who make requests beyond the scope of the original statement of work. Also, be ready to push back on your technical team to ensure they have "listened between the lines" and truly captured the essence of what the client wants.
We all know the client doesn't always know how to ask for what they really want. As the point person for managing the actual work, project managers need to have a thorough understanding of how various components relate to one another: What skill sets are required? How long is each part realistically going to take?
How else are you gonna call B.S. on a resource that's taking longer than they should, causing a delay for someone else, or entirely missing the boat on a requirement?
The third principle is connecting. While this tends to be the most exciting part of a technology project, it can also be challenging.
Connecting is where we bring people together with a solution. Depending on the project management approach, it could be only a few items at a time (agile) or the entire solution (waterfall). In either case, understanding the various personas that the technology is being rolled out to is crucial.
Who is closest to a business user role? This person should be the individual developing and delivering training. The closer a person is to the business, the more apt they are to think like a business user, speak like a business user, and be able to train a business user. The goal here is user adoption.
Now, help this new user connect the new technology to their day-to-day role. All of the listening you did up to this point will help guide the team in developing and delivering training that directly ties to the specific use case.
Make it as easy as possible for the client's team to grasp how, when, and most importantly, why to use the solution to complete various tasks.
The fourth principle, knowing, is all about the metrics, analytics, KPIs, etc. that a project manager is accustomed to measuring.
Metrics should be easy to measure and understand for both the project team and the client team. However, beyond the traditional PM metrics like timeline and budget, the project should include client-side return on investment (ROI) metrics. This is especially helpful in an agile project.
At the start of the project, the client and project team should come together to determine which business side metrics will be used to determine project ROI. At that point, the team should establish the current baseline measurements and determine what the measurable ROI metric will be once the new functionality rolls out.
As that functionality is completed and introduced to the team, the business should continue measuring performance against the baseline and share that as a part of project success metrics.
Providing this level of information gives confidence to:
If you have been tracking these four principles - Listen, Understand, Connect, and Know - you might notice a simple acronym: LUCK.
The LUCK Principle compiles four simple terms that can be applied to any relationship or process. Want your PMO to be Powered by LUCK? Reach out to C5 Insight by calling 704-895-2500 for more information.
The complementary paper includes over 12 years of research, recent survey results, and CRM turnaround success stories.
This 60-second assessment is designed to evaluate your organization's collaboration readiness.
Learn how you rank compared to organizations typically in years 1 to 5 of implementation - and which areas to focus on to improve.
This is a sandbox solution which can be activated per site collection to allow you to easily collect feedback from users into a custom Feedback list.
Whether you are upgrading to SharePoint Online, 2010, 2013 or the latest 2016, this checklist contains everything you need to know for a successful transition.