The Role of a Project’s Lead Technologist

August 25, 2011 — Bruce McGraw

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Do not hoard information – screen it. Then pass along as necessary both up, laterally and down.
  7. 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!
  8. Do not be defensive, but be willing to explain technical decisions when asked. Listen to other’s ideas.
  9. 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).
  10. Stay calm even in the face of unexpected challenges or problems.

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

Posted in General Project Management, Leadership, management, Project Management. Tags: , , , , , , , . Leave a Comment »

Project Management – the Rest of the Story

August 18, 2011 — Bruce McGraw

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.

Horse-trading

Organizations have formal processes for resource management (Tools for Resource Management – The Survey Results and Hey PMs if resource management is so important, why don’t we do it better?). However, informally, project managers sometimes swap highly skilled, but scarce, labor to solve a problem or meet a deadline. Other managers keep score within this informal system and it behooves you to know the value of your assets and those on other projects.

Dealing with Clients

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.

Well, that’s the rest of the story. Please add your own examples via your comments.

 

Posted in General Project Management. Tags: , . 1 Comment »

The Importance of Project Planning – PMBOK Chapter 3

August 11, 2011 — Bruce McGraw

OK, it has been a while since I talked about the PMBOK and I wanted to continue a series of posts on PMI PMBOK areas (started with “What is the PMBOK all about”.  This week we look at one of the critical areas that many PMs shortchange in managing projects – planning

“No battle plan survives contact with the enemy” is a bit of wisdom about the world alternately attributed to Helmuth von Moltke the Elder, Erwin Rommel, Carl von Clausewitz, Colin Powell and Murphy’s Laws of War. Yet, military leaders continue to develop plans for every imaginable contingency. If plans are destined to fail in the real world, why should we as project managers bother with planning?

Plans rarely fail entirely. Rather, details of a plan require changes as factors outside the control of the PM require responses that deviate from the original plan. However, a project plan provides a roadmap of key destinations (milestones) and a timeline to reach those locations, even when detours become necessary.

Of course, the PMBOK addresses project planning in detail beginning in Section 3.4. It suggests that a project plan encompass:

  • Scope
  • Activities
  • Resources
  • Schedule
  • Quality assurance
  • Risk analysis

In the discussion, PMBOK acknowledges that, “as more information is gathered and understood – which is their way of saying contact with the enemy — additional planning may be required.”

Types of Plans
Creating a project plan is not a trivial exercise. The project manager needs to spend time gathering requirements from a variety of stakeholders and working closely with key technical staff to identify strategies and risks. For large or complex projects, creating even the initial plan may take several weeks. However, not all projects are “created equal” and some may not justify this amount of effort. Sometimes a project plan can be created on the back of an envelope (and, of course, captured in more detail during documentation – MS Excel is probably the most popular way many of you do this.)

  • Exploratory Plans: these often begin with a conversation and some, “what ifs.” A creative developer has an idea for a potentially useful software tool or an alternate approach to solving a vexing problem. What makes these thought exercises a project that requires planning is the need for resources. It is one thing to have an idea. However to try it out and test its utility, someone has to approve the objective and the allocation of hardware and human resources. Even exploratory projects need a statement of the problem, a sequence of steps, a schedule and a method to evaluate outcomes.
  • Agile Development Plans: I discussed Agile Development methodology in “Project Management and the Agility Factor” as a style of project development that focuses on short iterations of feature development. Kent McDonald, writing for ProjectConnections, suggests that a Project Plan for Agile Development would only cover a period of two to four weeks. “During those iterations, all of the necessary work to take features from an idea to a working product is completed …” Each iteration begins with a feature-based plan that includes detailed tasks, schedule and deliverables.
  • Traditional Waterfall Plans: When waterfall development method is used on a project, the project management plan covers the life cycle of the project in discrete steps beginning with requirements analysis followed by design, implementation, test and maintenance. Because plans developed for waterfall method projects may cover months or even years of activity, these plans are more likely to require re-planning driven by external events.

Characteristics of a Good Project Management Plan
Here are a few tips to help you make a better project plan:

  • Cover all the bases listed in PMBOK
  • Clearly defines the scope of the project
  • Show dependencies between tasks as part of risk management
  • Comprehend resource loading and realistic levels of effort
  • Reflect awareness of project risks and allow time to understand and mitigate them
  • Accompany the plan with a communication plan that explains goals, tasks, schedule and performance information with key stakeholders
  • Include qualitative measurement of deliverables tied to project requirements (Focused on outcomes and not just widgets)
  • Help developers, team leaders and users understand the project and their role in its success
  • Make sure the plan is sized appropriate to the scope and size of the project (“Not too big, not too small but just right”)
Posted in Best Practice, General Project Management, Planning, PMBoK. Tags: , , , , , . 4 Comments »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 383 other followers