Showing posts with label budget. Show all posts
Showing posts with label budget. Show all posts

Sunday, April 20, 2008

Resourcing Project Managers

Ironically, although resourcing production team members is a significant part of a Project Manager's role, very little focus is placed on resourcing the Project Managers themselves. Because of this, I've encountered many Project Managers that are overwhelmed, worn out, and in many ways, ineffective. Over time, I've developed some generic strategies to help Directors allocate an appropriate amount of work to Project Managers. In this entry, I'll discuss some simple ideas to help get started.

Base It On Budgets - As with any project team resource, a Project Manager's full work load should be based on the monies available in project budgets to support their work efforts. In other words, the hours allocated to Project Management within a project budget must dictate how many hours the PM dedicates to the initiative. As an example, if a Project Manager has 40 hours in a budget, and the project will be completed within four weeks, the PM should be averaging ten hours per week on that project. This is often how we resource production team members, and the Project Manager should be no exception to this very basic approach.

Portfolio Management - In this scenario, I am defining a portfolio as all projects associated to a single client. Allowing a PM to manage all initiatives for one client organization may not follow any mathematical equation for total hours worked, but the benefits of a Project Manager becoming familiar with multiple facets of a client's business represent added value to that client over time. The Project Manager will develop a global view of the client's online business, putting them in a position to identify synergies in marketing or technical strategies. If this approach is used, it's critical that the Project Manager's direct supervisor monitors work load closely. If the portfolio grows past critical mass, it may make sense to bring on a second PM to share the work, as long as project budgets support that decision.

Ultimately, a Project Manager's workload must be measured and monitored like that of any other production team member. Project hours must be charted across project duration, to understand how the ebb and flow of project work will affect a PM's workload over time. Weekly meetings should be held with each PM on your team to discuss any anticipated issues and to determine contingency plans for busier periods. As I've said before, when a Project Manager drops a ball, it tends to have a ripple effect on all their projects, so this is a case where an ounce of prevention is worth a pound of cure in preserving the quality of all projects through productive project management.

Sunday, February 10, 2008

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.

Sunday, October 14, 2007

A Word (Or Two) On Quality

In the world of interactive project management, the promise of quality has become cliché. Quality is sometimes seen as an incidental to each client delivery, as opposed to an independent, critical phase of the delivery. Because quality control is commonly compressed at the tail end of a project, the overall commitment to the caliber of work produced is inherently compromised. There is, however, one person that can change this negative trend - the Project Manager. Here's how every Project Manager can do their part to save the interactive industry from a decline in excellence:

- Include testing in the price to client: Always incorporate costs for a thorough quality control phase into the budget of your projects. It is a Project Manager's job to show value in the process and methodology they employ. This means you must be able to demonstrate the benefit of each project phase to a client in order to justify the cost of a job. By doing so, you will be able to recover any time spent against testing in the original price to client, and you'll be able to articulate the work effort behind the line item cost. This will also make you accountable for the integrity of the final deliverable, providing additional incentive to do a thorough, proper job.

- Include a testing phase in your project timeline: I suspect the primary reason that testing is short-changed is time constraint. Project teams are often focused on completion of the build, forgetting that actual completion is achieved at the end of successful testing and bug resolution, not at the end of the build. If you incorporate a quality assurance phase into your timeline, your team will be able to work towards this project milestone from day one, allowing sufficient time towards the end of the project to work through the proper cycles.

- Don't do the testing yourself!: One of the worst mistakes a Project Manager could make is to complete testing themselves. Flawless quality assurance is an expert skill that is developed over time. Like Project Managers, professional testers will have solid process and methodology to support their efforts. When time and budget are running out, some Project Managers will take on the quality assurance portion themselves, thinking a quick review will suffice - this is never the case. Leave testing to professionals - facilitate the process, but don't overtake it if you intend on delivering a perfect product.

In summary, do not take quality for granted - designers, writers, developers, and even Project Managers will make mistakes. Quality assurance is the catch-all to identify and resolve these issues before client delivery. Flawless execution will always be remembered, and will go a long way towards a good name for you and your firm. Insist that quality be the golden rule for every project you touch.

Wednesday, July 11, 2007

How to Manage Scope Creep

As a continuation of my last entry, The Art of Scoping, I wanted to explore the management of scope throughout the life cycle of a project. Establishing initial scope and cost are the first step in a project - the responsible execution of the scope, however, requires diligent management through the identification of any elements or nuances that should be considered additional. The concept of items that fall outside approved scope is generally referred to as 'scope creep', and it is a Project Manager's duty to flag these elements for resolution.

How do you identify scope creep?: Scope creep is one reason that precise, clear project documentation is critical. In order to identity scope creep, a Project Manager must be able to prove that a given item falls outside the original agreement. The best way to do this is to reference a project plan, project charter, statement of work, or other similar documentation. This means project documentation needs to define the work effort of an initiative in a very detailed manner. More importantly, exclusions and assumptions will also support the identification of scope creep by clearly spelling out any items that are considered additional work.

What do you do when you identify scope creep?: When you are confident that the client or internal team has requested an element that is out of scope, it's important to flag the item as such so that you manage expectations. When you do this, clearly define what is out of scope, why it is out of scope (referencing the original agreement and documentation), and what the impact might be to the project if you move forward with the out of scope element (the impact could be to the timeline, budget, or both). Ideally, you want to be able to go back to your client and suggest a solution - this could be a simpler solution that could be accommodated within budget, a cost for the additional work, or a plan to execute the additional work in a subsequent phase of the project. Regardless of your solution, be very clear, and work with your team or your client to find a resolution together.

Damage control: When you identify scope creep to your client, this may result in a very awkward situation. Many times, clients will request items without realizing they are out of scope. As much as you need to protect the project budget, ultimately, your relationship with the client is more important, so don't assume the client is deliberately trying to get something for nothing. Clients will often become frustrated and upset, but this also presents a key opportunity to strengthen your relationship by resolving the matter. Be transparent with the client to build trust - make sure the client understands why the item requested is out of scope. Have a discussion about options so that the client contributes to the solution and feels comfortable with the outcome. As a Project Manager, you need to be prepared for these situations, so do your homework by sitting with your team first to understand the details.

Managing scope creep is one of the more difficult parts of a Project Manager's job, but solid documentation, clear communication and detailed information will minimize any risk to the project and the client relationship. When in doubt, draw on the expertise of your team to determine a few options your client can choose from. In the end, this will help ensure your project are delivered on budget and on time.

Friday, June 29, 2007

The Art of Scoping

The core objective of project management is delivering initiatives on time and on budget. In order to do this, a Project Manager must possess a combination of interpersonal skills, forecasting, risk management, problem solving and more! Regardless of skill level or experience, however, a Project Manager will have trouble delivering an initiative on time or on budget if the project wasn't properly scoped to begin with. In this context, scoping relates to the estimation of work effort and hours allocated to a given project for all the resources assigned to it. At a core level, it is the 'make or break' element that will drive a project from start to finish, and it is, without question, an art.

How do you scope?: Scoping happens very early on in the project life cycle - ideally before a client commits to the project. In order to properly scope an initiative, the person responsible must have a deep understanding of the production cycle, as well as the role of each contributor. In other words, who will touch a project, at what point, and how intensely. This information will determine how many hours each resource will need. This requires a grasp of the 'big picture', and an appreciation for the nuances and risks of the project. The person who is scoping a project must ask themselves 'what if...?' for any number of potential scenarios that could upset the original breadth and depth of the project. As an example, what if the client-provided content isn't written in a manner that's appropriate for the web? Who will be responsible for structural editing, and how intense will this effort be? If your team will edit the content, it will change the scope of the project because additional hours will be needed to complete this task. Identifying these project pitfalls is a key component of the scoping process, which leads to the next point....

Necessary companions of scope: Anyone who has worked with me will know I am as focused on project assumptions and exclusions as I am on the actual scope of a project. I describe scope as drawing a box around project deliverables. Scope is about identifying what will and will not be done to deliver a project, so that the client and project team agree to the end product. In order to do this, the scoping exercise must result in a definition of what is included, as well as what is excluded and what is assumed to be true. These are fundamental elements in the equation which will help clearly solidify the commitment of the agency and client alike. As a rule of thumb, a Project Manager should never provide a quotation or project scope without accompanying assumptions and exclusions.

Scoping is a complex and critical skill, which needs to be developed over a long period of time. Remember these fundamentals when you scope, no matter how small a project may be - you will do your company and your clients a disservice if you take any shortcuts. Practice by scoping smaller initiatives and by identifying assumptions and exclusions for them. After some time, you will feel confident enough to tackle larger projects. The test for any scope is to execute the project and compare actual work effort (typically measured in hours) to the hours you originally scoped. Identify the differences and learn from them. Doing this will ensure that each project you scope is estimated more accurately, resulting in improved profitability for your company.

Wednesday, April 25, 2007

The CMS Debate - How to Counsel Your Clients - Part 1

At one point or another, every interactive Project Manager will be asked if implementing a Content Management System (CMS) is a good idea. For those who aren't familiar with the terminology, a CMS is just what the name suggests - an application that allows the content of a website (including images and sometimes even navigation) to be added, updated or removed using an interface which doesn't usually require any HTML or technical knowledge. The common objective of implementing a CMS is generally self-sufficiency on the client's end, as well as decreased external maintenance costs. The response to the question regarding a CMS has to carefully weigh many factors. Two primary considerations are broken out below. This entry will be continued with more considerations tomorrow.

Budget: A simple approach to determining whether a CMS is a viable solution is cost. Typically, a CMS implementation will represent a greater up-front cost, which should be off-set by reduced external maintenance costs long-term. It's important to note that although the client may save on vendor fees, the internal time which will now be allocated to website updates still represents an investment, and potentially a drain on resources as well.

Speed to launch: The CMS market is saturated with product options. Each product will vary, and an exhaustive (and often daunting) audit will be required to identify the appropriate solution. Factors such as up-front and ongoing costs, technology constraints, usability, product support and even language capabilities all need to be considered. Narrowing your search to meet the criteria can take many weeks, and securing stakeholder approval on a final decision before purchase needs to be factored into your timeline as well. In addition to the CMS selection process, there may also be a learning curve for the implementation team. Your technical resources, and perhaps even your designers, will need to learn how to develop within the CMS prior to commencing production. When all is said and done, a client's expected timeline may not allow for such a lengthy process leading up to development.

That's enough for now - more on the CMS debate tomorrow...