Every project is proposed, reviewed, and approved before it gets to the project team. I’ve been fortunate to be a part of projects from the perspective of the agency being hired by a client, as the client hiring and agency, and as a consultant being hired by a client to make recommendations, implement, and essentially provide instructions on how to keep the project operational.
Further, I’ve been involved in going through the internal review process, on-boarding or being on-boarded, and handing a project off to another person.
In every instance there is a problem to be solved, an individual who made the request to have it solved, and an individual or a committee who reviewed it and agreed it needed to be solved.
This means there is documentation and there are people you can talk to in order to learn more. When I say answer and act, I mean you need to consider the questions that you should be asking and you will need to be able to answer questions of all sorts from a wide range of people
When I think I have a clear understanding of the project, I ask the person who made the request if I could recap what I think they wanted to see what I may have missed or misunderstood. I also try to speak to the person who approved it to determine if they have the same understanding as myself and the person who made the request.
When introducing the project to the team, I emphasize the value of the project to the organization. If I am with an agency, the team needs to understand the value to the client and the value of the project to our organization.
No one wants to be told to do something and when they ask some version of “why?” the response can’t be “because this is our assignment”. If they understand the importance and the value of the work they are doing, they will be more invested.
What People are Saying:
“I am very impressed with this. Ross did a good job of thinking this whole thing through.”
Melissa Warner, President-Elect, HMC Council and Executive VP & General Manager, CME

Case Study
At Olympus there was a tremendous need to share information when it was decided and approved to build a new website. In short, the team was given permission to “blow-up” everything we had and replace it with something new.
The U.S. website would be built first and the solution had to be able to accommodate scaling up to accommodate hosting every existing or future country or regional site in the Americas.
The company had two primary business units that served a dozen medical specialties, there was also a pre-owned division, service, and repair. In total there were about forty key stakeholders, who all wanted a new website and who all had a different idea of what that website would look like.
In short they only cared about their section of the site. I had to educate people about what was going to be delivered, what the timeline looked like, how the site would function, and most important what I needed from them and by when.
I met with individuals and teams, sat down with them, demonstrated the solution, and explained why we did what we did and the benefits it provided.
The biggest struggle was getting content from all the product teams on all the products they wanted to highlight on the site. The struggle came by way of the fact that the project was so big that there was an assumption we would run behind and therefore when given the choice between multiple priorities the web site fell by the wayside.
When I demonstrated the site to the heads of the departments and they saw how close we were, they made the site the priority for their people and we got it launched within our window.
Getting ahead of the questions by anticipating them, using demonstrations to show instead of tell, and being pro-active with the teams kept us on schedule.
