Creating UC Project Leaders
Creating UC Project Leaders by Kevin Kieller
In my previous article, I asked “Who is leading your UC implementations?” and suggested you make use of “project leaders” as opposed to “project administrators” in order to improve the chance of project success. I defined a true project leader as someone who when confronted with an obstacle is able to gather the facts, understand trade-offs and make decisions.
But as a systems integrator or value-added reseller how do you go about finding or “growing” these project leaders? Admittedly I am still working on the answer to this key question; however, I can suggest key behaviors you can encourage and develop that are often demonstrated by successful project leaders:
1. Focus first on the What
There is a key difference between “what” you are attempting to achieve and “how” you are going to achieve it. Technical people spend most of their time debating the details of the “how.” This ongoing debate related to the mechanics of a solution often obscures and suppresses the more important questions and understanding related to the true project business objectives (the What).
Project leaders should make sure that the What is understood and documented before getting too far into the project.
Clear, understandable, measurable objectives are critically important and often serve as a “compass” that can help evaluate different implementation approaches. The correct approach, the right “how”, becomes the one that best meets the original defined “what”.
2. Understand key project management items: Effort versus Duration, Task Definition
In my experience project leaders do not need to be certified PMPs (Project Management Professional); however, project leaders do need to understand some key project management tools. In fact, sometimes “hardcore” PMPs may get caught up in the minutiae while overlooking the bigger picture.
A project leader must understand and work with the team members to differentiate between effort and duration during planning. Remember:
Elapsed time (duration) = Effort (Work) / Resources
Focusing team members on providing effort estimates (“It will take 20 person hours”) as opposed to duration estimates (“I’ll be done by next Tuesday”) is a key step towards more mature estimation and more realistic completion targets.
While accurate estimation is important, perhaps more important is a leader who ensures there is a common understanding of the assigned tasks. How will I know when the task is done? What does the deliverable from this task look like? These are key question that all team members should be able to answer with a common understanding.
3. Regular status and communication
Most team members are involved in several simultaneous projects. Project leaders should regularly re-orient the team and remind everyone of the overall project objectives. This is far easier when clear, concise and measurable project objectives were established at the beginning of the project.
Starting status meetings, which should be held weekly or bi-weekly, with a quick recap of project objectives is a good idea. Reminding team members of the project objectives can prevent unnecessary scope expansion. Team members often have lots of “good ideas” for additional tasks to undertake. Nonetheless, tasks that do not support the defined project objectives should be part of a separate project or a subsequent project phase.
4. Hold effective meetings
If you are going to take the time to hold a meeting do it properly. For any significant meeting (30 minutes or longer), send out an agenda ahead of time. This can be a simple email. After the meeting, follow-up with a summary of key decisions and agreed action items. Once again, this can be in the form of a simple email.
Without some static documentation, I have seen project teams meet weekly to rehash the same issues and fail to move forward. It becomes a bad version of the Bill Murray movie Groundhog Day.
5. Test plans
Related to the above clarity around task definition, many technical implementation tasks should have a validation process (i.e. a test plan) associated with them. Q: How do I know when the IM server installation has been completed successfully? A: When you can execute all of the tests in the IM Server Test Plan document and they all provide expected results (i.e. all tests “pass”).
Of course, being able to execute a test plan to validate the completion of a task or milestone requires that the project leader had the foresight to create and validate a test plan ahead of the implementation task.
6. Establish a project phase n+1
I have found having a “next phase” of a project is an excellent place to put good ideas or tasks that don’t belong in the current project’s scope. It is far easier to suggest that a feature will be implemented in the future than not at all. Without a “next phase,” users and team members need to “fight” to get the feature included in the current project phase – which often increases technical risks and puts more pressure on resources and timelines.
I don’t know where to find project leaders but if you find someone who is demonstrating the above behaviors then you have likely found one. If you can encourage and promote the above behaviors then you may be lucky enough to make one.
As the complexity of UC implementations increase, systems integrators and value added resellers will increasingly need to find or develop project leaders to scale their businesses.
"Contrary to the opinion of many people, leaders are not born. Leaders are made, and they are made by effort and hard work." -- Vince Lombardi, Professional football coach