Archives

Blog Stats

Admin

Networked Blogs

Every project that I have looked at over the years involving computers, software or technology had three key staff on them — The PM, the sponsor and the lead technologist (or some call them the Subject Matter Expert- SME). Selected by the project manager, the Project Management Office, program manager or senior staff, the role of lead technologist requires someone who can effectively balance technical leadership and design, while supporting organizational and project goals. Although the exact duties differ among organizations and projects, the lead technologist often is expected to:

Oversee or develop the system architecture and design

Work with clients to understand requirements and constraints

Create and present the project’s technical side to customers and senior management

Solve technical problems

Referee technical disputes

Recommend resources and tools

I could go on. However, I think you get the idea that this position can be extremely demanding. In my career, I have seen lead technologists save the backside of inexperienced managers and nearly destroy a project because of personality conflicts with junior staff. As a lead technologist or a developer moving into a lead position, here are a few suggestions that may improve your chances of success.

Get authority commensurate with the position – if you can. But remember that you are not the PM – and probably don’t want that job anyway! Be a support partner to the project manager.

Define clearly the expectations and evaluation criteria of the position – tempting though it may be for the PM to say, “and everything else assigned by the PM,” work with him or her to clarify expectations.

Practice communication skills. Lead technologists help program managers, executive management, customers and stakeholders understand the technology and its application to the project goals. Often they need to serve as translators for technology approaches and obstacles.

Be willing to say no. Sometimes through ignorance or bullying tactics, you will be asked to make technology violate the basic laws of physics or human nature. As lead technologist, you need to explain why an itch cannot be scratched or a request cannot be met. Be diplomatic, but firm.

Get to know team members skills and motivations. Do not overlook weaknesses because of friendship. Help build weak skills and enhance aptitudes. Be a coach.

Do not hoard information – screen it. Then pass along as necessary both up, laterally and down.

Work to build trust with the team by doing what you promise, admitting mistakes and recognizing (publically) achievements and contributions of team members. Give credit where credit is due!

Do not be defensive, but be willing to explain technical decisions when asked. Listen to other’s ideas.

Create level of effort estimates with input from the assigned staff. Do not base LOE on the time and effort you would take to complete the task (Not everyone is a super-star).

Stay calm even in the face of unexpected challenges or problems.

Please share your suggestions, tips and experience as lead technologists.

For those of you who have been reading this blog, you know that I have continued a series of posts on and about PMBOK and its codification of all the methods and tasks involved in managing a project. Today I want to mention a few tasks that PMBOK omits. As the renowned radio commentator, Paul Harvey used to say, “Here’s the rest of the story.” I have no particular order for these items so I will just present them as a collection of tips.

Meetings:

When I became a project manager many years ago (no off color remarks about my age!), I remember being surprised (and dismayed) by the additional number of corporate meetings I was expected to attend. These meetings were about governance, internal policies, inter-departmental coordination and company initiatives not related to the project. There were strategy meetings, rollout meetings, kick-off meetings and sheep-dip meetings

(For the uninitiated, sheep-dip is a term that refers to “… training that is planned and administered to everyone in the target group without consideration of any other changes in policies, procedures, or management of the organization.” according to Tom Jenkins & Susan Morris of Advanced Business Learning.)

In these meetings, I was often just a face in the crowd. However, attendance was taken via a sign-in sheet, so I figured I had to attend. I did this for many years before I learned how to discriminate between invitations I could safely ignore and those I had to accept.

Of course, as a new project manager, I expected to work closely with our project’s users and client. Stakeholder management and risk management are two of the pillars of a successful project management career. However, I was amazed at the number of times I was asked (read that required) to brief potential clients, the clients or senior management of other projects and important people who were just passing through. I was rarely given insight into why my presence and information were important. I just had a time slot on an agenda and a location.

You Don’t Really Own Your Budget

After excruciating hours of “level of effort” and cost analysis, followed by negotiations with the paying customer, you believe that you have a final project budget. You have shaved and come up with great ideas on how to stretch the dollars and make things happen on a minimum budget. Not so fast. I have witnessed management “taxes” that were subtracted from my project budget during execution. Circumstances changed in the management chain above me and my project overhead went up 10%. As the project manager, you are expected to figure out a way to deliver the promised product or deliverable within the allotted staffing and schedule using 10% less funding. What? Yea, it happens.

You Can Be Demoted

As a project, and later program manager, I worked hard to develop rapport with my immediate supervisor and key decision makers in the organization. I also understood the importance of “org chart rank” to some people. Therefore, it was disheartening to be demoted by a reorganization that moved me down a notch or two. I still had the same responsibilities to manage my project, but now instead of being four levels from the decision makers, I was six or seven levels below them. My access to key people was replaced with an intermediary. Once this happened to me because our company was acquired by a larger company. The second time it happened, senior management wanted to reduce the number of direct reports for senior staff, so more middle management positions were created. It happens and you have to deal with it.