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.
Showing posts with label timeline. Show all posts
Showing posts with label timeline. Show all posts
Sunday, October 14, 2007
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.
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.
Tuesday, May 29, 2007
Sharing Accountability With Your Team
So - your team has been working on an intense project for your most important client. Launch is scheduled to coincide with an extensive national marketing campaign. All eyes are on this project, which represents a huge investment to the client. Every detail was planned out and documented and production has been flawless. The launch date approaches and suddenly the team flags an issue that can't be resolved in time for launch. There were plenty of opportunities for the issue to have been raised and resolved throughout the life cycle of the project, yet the team neglected to mention anything. Through all the review periods and checkpoints and documentation, this important detail was overlooked. Your team turns to you and says 'Just tell the client it will be late'. Your stomach drops and your mind races to come up with a solution, and in that moment, you feel completely alone, despite working with a large team. All accountability lies with you and the pressure is unbearable. This is a nightmare scenario for a Project Manager, and it points to a bigger issue - lack of accountability among the team! When the team feels disconnected from the end client, delays, issues and errors seem acceptable, and the Project Manager begins to feel sole responsibility for the entire deliverable. The million dollar question is, how do you turn this around? I've got some suggestions that could improve matters - give them a chance and you will see results.
Engage your team in 'thinking' as well as 'doing': No one needs a Project Manager who simply barks orders. A Project Manager needs to lead the team in terms of when things need to be accomplished, but not always how - leave the 'how' for your team to determine. Allowing your team to think through solutions will spark a sense of accountability and pride if they succeed. This will do wonders in giving your team a feeling of responsibility towards the deliverable. By engaging the team during the initial planning phases, they will feel more connected to the process and the outcome. Suddenly, when a challenge arises, the team will feel compelled to offer a solution, since they will feel a greater sense of ownership towards the work product.
Put a face to the client's name: Many times, a development team will never even meet the client. This creates too much of a disconnect because the client will never seem real to them. Put a face to the client name by involving your team in client meetings. Although you should always remain the point of contact, allowing your team to develop their own relationship with the client will push them to feel a greater sense of responsibility towards the individual who has contracted the work.
Educate your team: It is sometimes difficult for a production team to understand why a client needs things done a certain way. By educating your team regarding the client's overall marketing objectives, target audience, media activity, financial commitment and history, the team will begin to better understand the bigger picture, and how their work product contributes to it. As they learn more about the client's business, they will also be in a better position to offer additional solutions that could prove valuable.
The message here is that while a Project Manager leads a team, accountability for the project should be shared among each individual. Unless the team feels a sense of ownership and contribution, they will continue to work in a bubble that disconnects them from the project objectives and the client.
Engage your team in 'thinking' as well as 'doing': No one needs a Project Manager who simply barks orders. A Project Manager needs to lead the team in terms of when things need to be accomplished, but not always how - leave the 'how' for your team to determine. Allowing your team to think through solutions will spark a sense of accountability and pride if they succeed. This will do wonders in giving your team a feeling of responsibility towards the deliverable. By engaging the team during the initial planning phases, they will feel more connected to the process and the outcome. Suddenly, when a challenge arises, the team will feel compelled to offer a solution, since they will feel a greater sense of ownership towards the work product.
Put a face to the client's name: Many times, a development team will never even meet the client. This creates too much of a disconnect because the client will never seem real to them. Put a face to the client name by involving your team in client meetings. Although you should always remain the point of contact, allowing your team to develop their own relationship with the client will push them to feel a greater sense of responsibility towards the individual who has contracted the work.
Educate your team: It is sometimes difficult for a production team to understand why a client needs things done a certain way. By educating your team regarding the client's overall marketing objectives, target audience, media activity, financial commitment and history, the team will begin to better understand the bigger picture, and how their work product contributes to it. As they learn more about the client's business, they will also be in a better position to offer additional solutions that could prove valuable.
The message here is that while a Project Manager leads a team, accountability for the project should be shared among each individual. Unless the team feels a sense of ownership and contribution, they will continue to work in a bubble that disconnects them from the project objectives and the client.
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...
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...
Subscribe to:
Posts (Atom)
Posts
