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: 


  • Assign project resources, roles, and tasks.
  • Ensure the team is meeting objectives within the anticipated timeline. 
  • Track the project's overall budget as the team makes progress.


And all of these are correct pieces of the job. However, how a technology project manager does their job makes all the difference.


4 Core Principles of Technology Project Management

1. Practice Active Listening

The first principle in technology project management is to engage in active listening


  • Listen for subtleties in relationships, team dynamics, which resources are meshing, and which ones aren't. 
  • Listen for aspects of the design and deliverables that sound particularly challenging. 
  • Actively listen for the words and phrases "well," "but," "could we," "should we?" Each function as a signal that something could be causing a misunderstanding or a challenge. 
  • Lastly, this being the most essential piece, listen to what the client is really asking for. 


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.


2. Understanding The Scope and Client

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?


3. Connecting With Various Personas

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 howwhen, and most importantly, why to use the solution to complete various tasks.


4. Knowing The Data


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: 


  • The implementation team - showing that their work is making a noticeable difference.
  • The client team - proving that the solution can and will work for them. 
  • The leadership team - validating that they have made the right investment.


The LUCK Principle

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.