Don’t cop-out of a traditional project management approach, in favor of Agile, if you don’t have to. I appreciate the advice to just get started but know where your starting point is and start out right.

If you can know enough information upfront to rule out too much uncertainty, and plan the critical elements from beginning to end, then that’s where your focus should be. Rather than jumping in and making mistakes only to find out later that other stakeholders or other sources have already learned what you are toiling over is a waste of time and money.

Research and learn what you don’t know upfront. If enough can be known from the outset, then you can take a more conventional (tried and proven) project management approach to begin with. Standardize successful project work into operational norms and incrementally manage further project gains from there.

Organizational changes are large transformational projects. They require knowing enough information before kick-off to steer the company toward a fixed destination. You should have a really good idea what that end point is. Companies know where they are going at least 1 year out and should have goals for what they want to be 5 and 10 years out.

Company Change Initiatives effect everyone to one degree or another. You can take an adaptive project management approach, and you want agility as a company to pivot when needed, but you must tie down as much knowledge as you can to map out a more traditional approach than an Agile one the larger that your organization and project is.

In both change management and project management, you need to interview the key stakeholders, but your questions are different for each role because your interests are different for each role. Both types of management have a better chance (of deliverables acceptance and people adoption) the more that is known from the beginning.

Your stakeholders are your lifeline to information and getting you started off on your best foot with as much traction as possible. Here’s how you get traction, like loading the back of a pick-up truck to get the wheels to stop spinning.

Here is my takeaway #17 from one of the most useful practical books in my field, “Project Management for the Unofficial Project Manager”:

17) “You’ll want to get as much input as you can, as early as you can. Interview them thoroughly, and listen. The principle here is ‘Frontloading’, a term borrowed from the world of quality management…getting information totally clear up front…The more information you start with, the less uncertainty you’ll experience down the road.”

Jumping ahead the book explains, “The goal in your interviews with key stakeholders is to decipher or decode the pictures in their minds.”

Note: This comes from Chapter 3 “Initiating the Project: Move Ahead or Go Around in Circles?” (pages 48-49, 52)

It takes a little investigative work and asking the right questions for this picture to materialize. Most of us are not trained in interviewing, but it is an opportunity to get started off on the right foot. And it’s more straightforward than it seems. You are not looking to get into some kind of contest about who knows it all in any given subject. Your questions are project related.

You are looking for their idea of project purpose, description, desired results, exclusions, communications needs, acceptance criteria, and constraints. But more importantly, you are setting up a standard for what it will be like to work with you, a standard for the project, and a standard for what you will expect in working with them.

You are setting up a professional working relationship. Each stakeholder is not the only view you must consider for the project, but with regard to how they want you to work with them, their view matters most.

————————

STORY TIME:

I got bulldozed when meeting with a few managers above me in the pecking order, the first time I tried to meet with other stakeholders I would be working with in one organization. I was new and just starting to get a feel of the working culture and protocols in that environment. What I was finding was that the subject experts mostly worked in silos and departments mostly conducted their business separately from one another.

And yet, somehow my position was supposed to track workflows across several functions and a handful of departments through obscure processes. I knew it to be good practice to meet one on one with others I would be working with. I was familiar with working in settings where the right hand didn’t know what the left hand was doing so-to-speak, until they “got their heads together.” Apparently, I was going to need to build up trust somehow, not just with me, but across this organization too.

I didn’t expect this. I was hoping this work environment would be different. This was project management 101. Every time a project from my past was successful, it started with “identifying stakeholders”, and good communication, which included talking with said stakeholders about upcoming projects they would have a stake in. But this company had experienced some attempts at using project managers as consultants and they weren’t convinced it had enough of the desired effect on a company of their size.

I was asked why I wanted to meet with stakeholders. To which I replied, “to start building a relationship of trust.” To that I was told I would gain trust by delivering on the work. It was as though project work was expected to be a one man show. I got the impression they were skeptical of conversations away from my desk and outside of formal meetings for whatever reason. Thing is, gathering input is part of the work, a most essential part at this stage.

I was asked what I wanted to discuss with these other stakeholders from other departments. I explained something to the effect that I wanted to get all stakeholders’ feedback, and their perspective on what they understood the process to be, what was going right, and what could be better. That was met with resistance. I was told we were to be the authority on the subject and expressly tell them what we wanted.

I figured this interview I was having would kind of give me a state of the project work as it related to my position up to that point, but it gave me a fuller view of everything I needed to know about the goings on in the organization itself. This didn’t come to light in my job interviews, before I accepted the position. But that was okay. I was going to give this organization every chance for us to win together now. It took more persuasion, but I was able to convince them to give my strategy a chance.

I was given permission to speak with other managers from other departments, on condition that I bring my position’s trainer into the discussions. That was fine. I could use that person’s subject expertise, if related questions came up, but I feared the stakeholder interview would veer off in the wrong direction. Given my newfound understanding of the power structure and authority in this new environment, I also felt I needed to gain trust from key individuals first. I wanted to do it their way for a while before changing things up. I decided against meeting with other stakeholders at that time.

Don’t run your organizations or your projects in this way if you have a say in it: that is to say, in a way that has so little true collaboration, coordination, and communication between all interested parties (stakeholders).

———————–

I made the wrong decision. I was moving in the right direction to change the wrong way of work and I halted. It set the tone for the rest of my time in that organization.

Sure, they were the industry experts on current practices, but I was more expert on project management best practices. I don’t know if it would have been received better if I, or consultants before me, had done anything differently, but I do know professional project management could have made all the difference. If done correctly, properly understood, and implemented by a true team culture it can and does improve any size organization, and it is more than worth the investment when applied in the right form and function.

(Note: I should explain that the main work I was doing was more of an ongoing operational workflow, than it was project management. It was like keeping track of 100’s of mini projects, some of which I would be involved in initiating more than others. I kept track of different deliverables that would come in and out of the workstream at different times and each would flow at different paces. It did impact the organization at its core, and it taught me a lot about what is functional management, project management, and workflow management – something in between the two. It gave me opportunity for practical applications of project management refining my position, improving processes, and upscaling our product data in between functional work.)