Technical Project Roles

In this write-up I will discuss the Technical Project roles of three positions Planning, Engineering (Technical) and Integration (installation).  Often times there is no clear delineation of the roles and this can affect efficiency, scope and most definitely timelines of a project or process. Towards the end of the post I will put down the industry best practices for these three positions, as I would not want any of my peers thinking I just came up with an original thought on the topic.

The Planner

First, I will define the roles as they are traditionally defined, starting with Planning.  Planning is the role of ensuring that any project is developed to encompass the initiation of the project, through closing the project out.  The Planner is the person that is responsible for knowing the environment of the project, including key stakeholders, stakeholders, all the known unknowns, including the myriad of potential disruptions to a project, like other resources timelines, interruptions (holidays, other projects that are disruptive to the focal projects triple constraints (time, cost and scope) and the “political” atmosphere).

The Planners position is one that should not be assigned lightly, this person is ultimately accountable for the assurance that forward progression is disruption and barrier free.  Often this position is a “hey you” position, one that is assigned to the guy standing around the cooler with his hands in his pockets, but it should be assigned to the person with the capability to lead projects and develop plans on the move, this is sometimes referred to as “agile”.

The Engineering role

Next is the Engineering role, the role that will layout the design and ensure that all the I’s and T’s are dotted and crossed to ensure a fluid and successful project.  The engineer needs to have their ear to the ground and work with the planner and integrator to ensure that project success is captured and ensured.  This would include the technical aspects, some environmental aspects (some call this politics, though most of the time I call it speed bumps).  The engineer is to be the ear to bend, the voice of actuality’s and reality, they should be the ones that take the planners vision and align it to real world capability.

This role is another one of those need to fill with capability not just a body.  This person is ultimately responsible for ensuring that the technical layout is 100% inline with a successful achievable outcome.  This means that this person needs to be technically capable, empowered for success by leadership and understanding of not only the upper clouds of the project but way down in the weeds of what needs to be done.  Prior to handing off to integration’s, which are part of the initial planning, engineering and ultimately installation, the engineer should have the technical buy in and support of all key stakeholders, both technical and leadership.

The Integration team

Now that all the planning and the engineering is done for a project it is slid over to the Integration team. This normally comprises of a Team Lead and resident experts on the particular project that is about to be initiated.  If good management practices are in place then the team members are sent to training ahead of time, documentation is standardized and version-ed to maintain control and understanding and all updates are funneled from the Team Lead to key stakeholders.

It is important to note that by the time the Integration’s team has the project to run with, all of the speed bumps should be worked out, systems have been tested, baselines achieved and scheduling (meaning actual time that resources and money can be applied to) is planned out as far as humanly possible.  Now is not the time to be planning and troubleshooting documentation issues, now is the time to implement and integrate new systems into an existing operation.  The Integration’s team members should have been involved from the start and their inputs gathered and utilized so that a packet can be handed to the Team Lead and the project can then initiated with most known and unknown known variables accounted for.

The Process

If issues arise and there is a tight schedule to adhere to, then the Engineering team needs to pick up the slack, the Integration’s team is there to get the project done, handed over to operations and off the plate of the Planner and Engineering team.  Often times with poor planning and engineering the Integration’s team will be held accountable for schedules, scope and cost not being met, it is my experience that with proper planning and resource management there should never be failures, maybe setbacks, or even delays, but the project should ALWAYS be a success if all team members, key stakeholders and management have done their due diligence.

So now we are to the end and I know your wondering how did I pull this process together, am I some sort of genius? Maybe, but this is common best practice and most of what I have stated is well documented and here is that location for you to be able to ensure that I know what I am talking about and also to have a resource that you may use to ensure your Integration projects are a success.

References:

• Best Practices For Large It implementation or integration projects
• SYSTEM INTEGRATION:Successfully managing projects (I highly recommend this read)
• System integration ((MITRE always has good public view-able reading on industry best practices, and of note is the many additional resources in this article)

So See I did not just make up the above content, just simplified it and made it readable.  Please let me know your thoughts, your own pain points, or your own successes and how was that success leveraged.