As a project manager (PM), one of my top concerns in engaging on a new project is understanding the scope of work. Next, what are the skills needed to support and deliver the scope of work at hand? Many considerations go into this discovery, but one of the very first resources I prefer to have assigned is the Solutions Architect (SA) role.
Welcome to my new blog series; The Makeup of Technical Project Teams. Follow along this journey as I focus on how each role works alongside the Project Manager to deliver success across various types and scale of projects. Beginning with a foundational role, Solutions Architect should be identified early and brought in to lay the foundation to the success of the project. At the beginning of all projects, I ensure to layout roles and responsibilities, but let’s get the perspective from a few SA’s, themselves, on how they set up for a new project and how they expect to work alongside the PM to ensure successful solutioning. Read on as I discuss various project situations with various architects whom, collectively, have over 22 years of experience in this role.
PM: As a PM, I like to set roles and responsibilities early. What are typical project management activities that your PM covers that are helpful to you on any given project?
SA1: The PM is the person that really knows the high-level overview of the full project, the goals we are trying to reach and how individual tasks lead to achieving goals. On an Agile team, everyone should be responsible for their own work, but I appreciate that the PM that has the overview of the full picture keeps the focus on the things that are important. Scrum master duties are also important from a PM if not otherwise fulfilled.
SA2: Managing the board Is a huge help to an architect. To ensure we are keeping an eye on what is current what are we falling behind on, for an architect not to have to worry about the board is great. Also, leaning on the PM to handle communication with the client unless technical or solutioning communication is needed. Architect shouldn’t have to be worried about day-to-day communications with the client.
SA3: Running standups, making sure the backlog is as complete as it can be before the project starts, ensuring appropriate access to systems and tools that the dev team needs, making sure nothing is blocked. You can’t really kickoff a project until you have an architect, a backlog, and a project plan. Beyond that, managing the backlog, bugs and budget is the first line of defense for the client.
It sounds like a resounding answer of scrum master and client intermediary! In a later blog, I will discuss the overlap on scrum duties and how if a project is resourced with a business analyst, often Business Analyst and PM share scrum duties, but we will get to that in a later post. However, speaking of overlap in duties…
PM: How do you prefer to handle overlap in SA and developer roles? Ideally, an architect gets to just be an architect, but often (depending on project) engages in coding tasks as well. Thoughts?
SA1: If the SA is full time on the project, then it makes sense to have some bandwidth for development tasks as well, but if only part time on the project, the SA is more valuable as a guide to the rest of the development team. The focus of an SA should be problem solving, guiding, helping with onboarding/local machine setup. Ultimately, the SA should be higher level to help the whole project move forward (code management, pipeline management, deployment management, research to support larger tasks, etc.).
SA3: SA shouldn’t be doing day to day coding, hands on. Instead, SA should be reviewing what has been done. Sometimes, SA steps in to assist in more complex tasks or helps alongside dev team on a day-to-day basis. It’s important to consider those more complex tasks in the project plan to account for the SA’s time. Essentially, SA make the outline of the overall picture while the dev’s color it all in.
We all have an idea of what our role is on any given project, but as we know, sometimes those responsibilities change project to project. Therefore, it is so important to identify roles and responsibilities early and check in on them often. How do we best play to the strengths of the resources we have with most efficient use of the budget? Thank you to the solutions architects for chatting with me on the above topics. There is so much more to cover! Speaking of efficient use of budget, I will be back soon to relay additional perspectives regarding communications, client interactions and meetings with our Solutions Architects. Stay tuned!
