Setting Up A PMO

A PMO, or a Project Management Office, is the central hub of project management activity within an organization. The PMO is responsible for standardizing practice and procedure, documentation and template creation, metrics and measures of success. There are organizations with Project Managers that have not set-up a proper PMO. Instead, the Project Managers create their documents 'from scratch', and make up the rules as they go. This leads to tremendous inefficiencies, and it becomes difficult to build intellectual property when each person works in a silo. In this entry, I'll discuss the benefits of a PMO as well as some must-haves.

What's Important?: If you want to standardize PM practice, there are some basics that should be produced:

- Standard operating procedures: SOPs detail the steps involved in each repeatable task the team is responsible for. in an interactive organization, you may create standard operating procedures for things like storyboard review meetings, scoping and pricing exercises or post-mortems. The SOPs should be detailed, providing step by step instructions. Most importantly, the purpose of the task should be explained, to provide context and background.

- Templates: Standard templates should be created for any document that is produced frequently by the PM group, such as Project Plans or meeting minutes. Formalizing this documentation will ensure consistency in deliverables, and will help each team member produce quality information. Templates also provide an opportunity to identify gaps or requirements that are not being met. Ultimately, the goal of any PMO is to strive for continuous improvement - documenting the way things are done allows the team to comment on how things can also be done better. A PMO can help develop best practice over time.

- Industry standard information: It's critical that Project Managers understand basic information about the industry they work in. In the interactive space, this can include stats about high-bandwidth usage, user trending, or response metrics. This information should be stored centrally and updated as frequently as possible. It will contribute to the overall acumen of the team.

If your organization hasn't already done so, take the lead and begin assembling documentation to set up your own PMO. Don't be reluctant to tweak your set-up if it will meet the needs of your project management team. Solicit input and build up your assets over time. Eventually, your department will be running like a seamless machine.

Managing Project Scope

Ok - you're about to kick-off a project you're managing. The scope and budget are set, the team knows what they're delivering, and everyone is ready to begin. You're confident that hours have been allocated appropriately, but you also know how easy it is for scope to slip away from you - you need to keep a good handle on this project to ensure the team doesn't squander their hours and push the project over budget. In this entry, I'll review some solid tactics you can employ to progressively manage your project budget and maintain total visibility from beginning to end.

Granular Scoping: The first tool in your arsenal of budget management needs to be rolled out before the project is even approved for commencement. It's what I refer to as granular scoping, and it means that the budget should be allocated to each resource at a task level. In other words, don't estimate required hours in large lump sums - when you are going through the initial scoping exercise, ensure hours are broken down into as much detail as much as possible. This will allow you to subsequently assign and manage project hours in smaller steps, which will inherently provide you with greater control and transparency as your team consumes their allocated hours. The ultimate advantage is greater visibility regarding how long each project task actually takes. This information will be invaluable to you as you estimate future projects with similar tasks.

Accurate Time Capture: It amazes me to learn of interactive agencies that still are not capturing project hours through some sort of time sheeting system. There is no chance a Project Manager will have success in measuring project profitability with any comprehension if each resource isn't recording hours spent on specific projects. Ideally, resources will log how much time is used on each project task (back to granularity), so that you will understand exactly what areas of the project are most time consuming. This information will allow you to compare estimates against actuals, refining your scoping methodology by making corrections moving forward.

Milestone Reconciliations: If you've executed the first two recommendations, you'll also be able to complete this one - providing you with absolute clarity and opportunity to recover from potential pitfalls as you move through the project life cycle. Reconciliation is an exercise during which you analyze project completion (how much work has been done) in comparison to work effort (how may hours have been used). If you have broken down the scope and hour allocations in a detailed way, and hours are being recorded by each project resource, you will be able to reconcile at key points in the project to identify if you are over or under budget before the project is completed. IF you know you are over budget early on, you may be able to take action and correct this trend before it's too late to make a difference. Project reconciliations also present an opportunity for you to share accurate information related to scope and budget with your client. A client that understands how much effort goes into a project, and how the team is working to remain within budget, will be more amenable to paying for legitimate overages.

As a Project Manager, your most critical responsibility to the organization you work for will be scope management - it directly affects the bottom line, contributes to corporate success, client satisfaction, and professional achievement. While this task may seem overwhelming, it is within reach if you can breakdown work effort and measure profitability as you move through the project. Ultimately, agility will provide you with options - and understanding where your budget is at each stage of a project will allow you to react and manage project scope successfully.

Making The Transition From Developer to PM

Every time I publish a job posting to hire a Project Manager, I receive applications from candidates who are working as developers. These individuals are seeking to transition laterally into a new role. With interactive Project Managers being harder to come by, I've decided to consider how a developer could bring value to a project management role. In this entry, I'll share my personal point of view on the good and bad of this substantial transition.

The Bad: I've been witness to more than one developer migrating into a PM role. The greatest challenge they will face is self-created - many 'outsiders' underestimate the complexity and stress of the job. As a result, their indoctrination into project management is clouded by immediate disenchantment and anxiety. Renowned author, Seth Godin, speaks about a concept called The Dip in a book he published. The basic premise is that anything worth achieving is worth working through - particularly in the harder times, when many people tend to give up. Project management is a career that can be trying, but if you're able to stick with it when it gets tough, the rewards on the other side of the challenges will be worth the effort. Developers moving into project management must remember that - give it time and put in the effort. In the long run, it will pay off.

The Good: Transitioning from developer to Project Manager is not entirely a bad decision. In fact, there are some distinct benefits with this scenario:
- An understanding of the full technical development process.
- A good grasp on how client requirements can be achieved technically.
- Better judgment relating to time estimates for technical work effort.
- You speak in developer 'language', making for improved communication with those resources.
- An outside perspective always sheds light on how things may be done differently (better).
- A methodical, logical developer who relies on thorough documentation may find some of these qualities translate well as a Project Manager.

The landscape of the interactive space is changing very rapidly. More work is being outsourced off-shore, and as a result, technical work may diminish, but the need to project management will only increase. If you are a developer considering making a move to project management, due diligence is required to understand the reality of the job. If you work with Project Managers, pay closer attention to their responsibilities and contributions - ask them questions - most will be happy to give you some insight. Also consider the short and long-term advantages of such a move. It is a big decision that needs to be planned out and assessed.