The Power of a Content Deck

One of the challenges of web development - particularly when you're using a waterfall approach - is to bridge together the discreet documentation the team produces, so that each individual element is part of a larger whole.  Documentation produced by tech should reference and leverage documentation produced by information design, and so on.  Not only does this help present a cohesive picture to the team and client, these references will be useful come development, when the team will be expected to stitch each piece together into a single product.  Over the past year, I've focused on leveraging the content deck as a key document to help tie together supporting assets with great success.

Why the content deck?: The content deck comes at a key juncture in the life cycle of an interactive project - it is driven by information design, but will inform creative design.  It is a lynchpin for the team, touched by everyone.  More importantly, it may be the only complete reference to the site that exists.  Wireframes and storyboards are often only produced for key or unique pages, but the content deck will likely include copy for each and every page of the site.

What to incorporate: Beyond actual copy, the content deck should reference and incorporate the following elements:

• Numeration from the information architecture and wireframes - this allows an individual to understand exactly where individual content elements will live within the site and on a given page.  Not only will this will help the client greatly during content review, which can be a disjointed experience, it is necessary for the technical team, who will have to populate each website page with the proper copy.
• Multimedia files and server location - most sites include photography and/ or video, and the content deck provides an ideal opportunity to reference which specific media assets should be placed on which screens.  Again - the content deck may be the only complete reference you have to the entire site, so it's a simple and easy way to pass this information along to the technical team for the build.  But, don't stop at the image or video name - include the location of that file on the server, or on an external social media site, as well, so the team will know where the asset currently lives.
• SEO data - title tags and meta descriptions for individual pages can also live in the content deck.  This means the tech team will have a single place to refer to for all this information, instead of disparate documents they'd otherwise have to try and connect to one another.

Improvements to the way in which websites are built can easily be made by streamlining our work process.  Consider maximizing the value of the content deck by incorporating much more pertinent information than simply copy.  In the context of web development, the old saying, content is king, can be tweaked - content deck is king.

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.

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.