Introductions. 30 minutes of instruction 20 minutes of discussion

Size: px

Start display at page:

Download "Introductions. 30 minutes of instruction 20 minutes of discussion"

Benedict Cuthbert Briggs
5 years ago
Views:

1 Digital Project Management Basic Training MODULE 1 Basic Training This module follows chapter 1 Basic Training from the book. Estimated instruction time: 1 hour 10 Introductions 30 minutes of instruction 20 minutes of discussion Introductions Bathrooms, breaks, device use. Welcome to the first comprehensive course on the fast growing field of Digital Project Management This course is not about theory or marketing strategy It details a widely proven, real world, practical approach to managing digital projects that was developed by world class leading expert, Taylor Olson and used successfully at Fortune 50 corporations, and to train numerous project tteams around the globe. The author, Taylor Olson, is an expert in the fields of digital project management and global implementation This course is based on her book entitled: Digital Project Management: The Complete Step By Step Guide to a Successful Launch. Although the course materials closely follow the chapters of her step by step guide, to gain the full benefit it is necessary to also read the book. It shares important insights and material that would be difficult to convey in a fully comprehendible manner in slide format And in turn, the course material enhances what is presented in the guide by incorporating exercises and participant p discussions and collaboration. Digital Project Management: The Complete Step by Step Guide to a Successful Launch is also useful as a desk reference to refer to as needed while working on either a complex or simple digital project. Attention to details is critical on these types of projects, and missing one part of the process can cause failure when it comes time to launch. Icons designed by Freepik from Flaticon.com licensed by Creative Commons BY 3.0 Copyright 2015 by Taylor Olson 1

2 Digital Project Management Basic Training Many believed that project managers could lead any type of project, as long as they knew how to create schedules, budgets and status reports. But this was unfounded, and led to disaster. The project manager is the leader of the team and of the process they follow. Without the proper training, project managers were left trying to lead a team of resources without understanding what their roles or responsibilities even were. It resulted in projects where the appropriate business and technical requirements were not documented, leading to inaccurate budgets and confused development and QA teams. Developers did not know what exactly to build, and the QA teams had nothing from which to build their test scripts. Sitemaps were never created, which are very important because they are the basis by which Information Architects develop their user experience recommendations, and website administrators build the actual site structures. Schedules were never delivered, because the project managers had no idea what was supposed to be happening, or in what order. In order to create a schedule, one has to first understand the process. Without schedules the team has no process to follow; they don t have delivery dates for their assignments, and important steps are missed. Search and analytics teams were left out of all planning discussionsand therefore never provided their recommendations in time for them to be implemented. Websites either crashed or never really got off the ground when infrastructure and bill of materials review steps were skipped. Ever read about what happened with healthcare.gov? They never made it off the ground because their infrastructure wasn t prepared for the number of visitors it received. Test cases were never written, leaving QA teams dead din the water without ih the documentation needed ddto accurately test the projects. 4

3 Digital Project Management Basic Training This training is broken up into 11 modules. DO: [Read the modules on the slide] 6

4 Digital Project Management Basic Training This is the Rollout Process that our training is based on the 30 key steps. It s called the Rollout process because it was originally developed as a guide for building brand new digital projects from scratch and then duplicating (or rolling out) that same experience into multiple markets and languages. The process is broken out into two distinct phases. Plan and Define, and Construct to Close. The Plan and Define phase consists of the resourcing, budgeting, documenting and planning activities needed to lay a solid foundation. The Construct to Close phase involves the entry and organization of content, testing, cutover management and transition to operations. This training was written to help one understand the concepts behind each step, how each of the steps relate to one another, and the risks associated with not following through on them. Everybody should have received two copies of the rollout process along with your training materials. (Note the DO: process is also provided in the Participant Reference Guide if available to the participants.) [Hold up a copy of the process and make sure everybody has both copies] One copy is for you to track along with and make notes on while we go through the course, and the other copy you should keep clean so that you can take it back to your office with you for reference. 12

5 Digital Project Management Needs Assessment This graphic could be of benefit with understanding the purpose of the gap analysis. Where are we? For our project this would refer to Jetzen s current website. And then Where do we want to be? The space between these two answers is the gap. ASK: But how are we going to conduct our gap analysis? What is our Where we want to be point? LOOK FOR: [solicit answers and look for the following] Request for Proposal. Comps from the Creative Team. Notes taken from a hallway conversation or through an . The Where we want to be point comes from either the RFP, the comps, through those vital hallway conversations, or perhaps the client is leaving it up to the agency to develop a better solution. Optimally the new solution will come through a combined effort with the client, creative agency and the production team all working together. For our project, we re going to take the optimal approach where all teams are working together to come up with the best solution for a world class, global website. As often is the case, we ll assume that the clients first worked with their creative agency to come up with some comps. Then those other two boxes How do we Get There? and Are we There Yet? will come later. ASK: By the way, what s a comp? 38

6 Digital Project Management Needs Assessment At this point it s not necessary to explain how to achieve the goals we have listed, we re just noting that they need to be accounted for. Now that we have the Gap Analysis ready, it s time to present it to everybody at an all team workshop. The purpose of the presentation is to make sure all parties clients, creative, production, etc are indoctrinated into the project and can agree on what the deliverables are. This will lead us to business requirements, budget and schedule. Here are the major points we need to cover during the initial workshop we can actually use this as our agenda: 1. Business lead (client) name and introduction 2. Agency partner names, roles and responsibilities 3. Project name and objectives 4. Review of comps or initial requirements 5. Gap Analysis presentation 6. Confirmation of next steps 46

7 Digital Project Management Documentation It s a good idea to start a first draft of the BRD prior to going into the first workshop that way we can take notes right inside of it as people talk. Simply make a section header for every known business requirement gathered from reading through the gap analysis in advance. Then, as the gap analysis is presented, and different team members start mentioning specific business or functional requirements, we can easily add them to the document. In addition, we can confirm with the team any requirements that we ve been able to discern so far. The internet has lots of examples of Business Requirements Document templates from which to choose if your company doesn t already have one in place. Any format is acceptable as long as it provides the team with everything they need to understand what the clients are asking for. It could be done in a spreadsheet, text document or slides. Left brained folks can be pretty averse to reading through documentation, so it s sometimes nice to take the BRD and throw it into some slides to make it easier to digest. 61

8 Digital Project Management Documentation For this type of project costs are created by either resources or requirements. Let s start with requirements. To create the budget first make a list of all of the individual requirements listed in the BRD. Having these broken out separately will be a huge benefit during production. First, if one of the projects goes way over budget, we ll be able to track those costs and pinpoint exactly what went wrong and where, and either fix the problem or add it to our learnings for next time. Second, if the client needs to decrease the budget, they ll be able to easily review what everything costs and simply delete as needed. Third, as the functionality of each project is developed through the course of wireframing, we can easily adjust the individual costs without making the entire budget appear to be ballooning out of nowhere. Let s take a shot at creating a budget for one of our requirements. DO: [Advance slide to review table] Start a spreadsheet and ask all the resources how many hours they ll need to bill against each requirement. Then, it s simple math to multiply their hourly rate against the number of hours, and add them up. Do the same thing for each of the business requirements, and just add the final total to the budget estimate that the client will see. 72

9 Digital Project Management Communication Now that we have a sitemap we can start to take an agile approach to the production assignments. The dictionary describes the adjective agile as quick and well coordinated in movement, and this certainly applies to what we want to accomplish with our project plan. We ll need to create a wireframe for just about every page of the website, with the exception of pages which are based on a template or are repeatable. But, instead of waiting for the entire set of wireframes to be ready before we can start the review process, we ll take an agile approach by breaking the sitemap into groups that the IA can handle one at a time. This way, after each group of wireframes is ready we can move them on to the next phase of production (styling) while the IA starts on the next group of wireframes, and so forth. This way we keep several resources working at the same time in a quick and well coordinated manner. To better understand this concept, let s take a look at the sitemap and decide what the various groups should be. The IA can help you with this, since they ll have a better understanding of how much work will be involved with each section. By the way, these groups can also be called sprints, bundles or packages. Take your pick. For this course we re going to call them sprints. ASK: Looking at this sitemap, which pages do you think our first sprint group should consist of? 100

10 Digital Project Management Information Architecture By looking at the sitemap we can quickly determine which pages link to an external page, which are applications, which are normal content pages and so forth. Notice that application pages are represented by checkered boxes, and pages that direct users to an external site are shown as boxes filled with dots. It doesn t matter how the pages are shown visually, we just need to make sure that there s a key somewhere on the page indicating which is which. Another very important reason to make a sitemap is to present the global footer and header navigation strategy. The sitemap is now acting not only as an outline, but also as a tool that the IA uses to create and think through the strategy. DO: [Advance slide to reveal arrows] In this example the global header and footer are represented in the grey boxes on the top and bottom of the page. We call them global because they ll stay static throughout the entire site always available as an anchor for the user to see where they re at and how to get around. 140

11 Digital Project Management Analysis There are several factors that effect search engine optimization. Content Optimization is the act of making sure the headlines, paragraphs, alt tags and image captions all include keywords and phrases that the SEO team has indicated rank highly with search engines. Meta Data is the behind the scenes code that connects our site s content to search engine searches. Our clients often engage in Paid Search Campaigns to ensure certain keywords or phrases are linked with their website s content. URLs are used by search engines to help determine page content. A linking strategy can be used to build Relevant Link indication. And the Image Naming Convention we give to the pictures on our websites are also used by search engines to determine page content. Conversely, having a lot of Dead Links on a page or within a site lowers our SEO ranking. And if a page is slow to load due to heavy Page Weight we can also lower our significance. 186

12 Digital Project Management Development Communication with the development team is imperative. The problem is that these guys and gals don t usually go to the status meetings, and they have little to no direct contact with the team. They d rather stay at their desks and get their work done instead of sitting through meetings that may not necessarily pertain to their particular assignments. And I don t disagree we need them to focus on the tasks at hand, while the client facing team handles external communications. ASK: What is the best way to communicate with the developers? Do you like to call them, stop by, what tactics do you use? DISCUSS It is the project manager s (PM s) job not only to communicate complicated technical concepts from the tech team to the nontechnical folks, but also to communicate non technical business requirements back to The tech team. 226

13 Digital Project Management Development Assessment: If the client decides that the change is a good idea and that they would like more information, we put it through the normal process that we follow for all other requirements. Note that we may need to get back on the schedule for any resources required for the assessment, if they ve moved on to other projects. A gap analysis is completed first basically determining what we d need to do to implement the change, and then basic business requirements are documented so the production team has enough information to provide their estimates. The budget is created and run through internal management for approval, and the schedule is assessed. DO: [Advance slide] Core Team Evaluation: Remember the spaceship model builder idea that someone came up with? The one that built little plastic models using data captured from the customer s configurator creation? (this was briefly mentioned on slide 81) Using this as an example, the team assessed that it could be done, but the incremental costs would be $80,000 and it would also extend the timeline. 236

14 Digital Project Management Preparation Test scripts should start out with the project name and some pertinent project information as shown here. This is an example of a test script written for the contact form. The form can contain a number of different elements, but for sure we want our testers to list their name, the date the test was performed, what was tested (test name), and the testing environment. The test cases give the tester specific instructions for what to do, leaving nothing to chance. Step 1, for example, has the tester opening the homepage for and just confirming that the homepage does indeed appear. Most test case templates provide a description of the expected result along with a comment area for the tester to explain what the actual result was. In addition, there s a place to list if the system passed or failed each step. The example we re following shows a very small list of steps for the contact form just for our example in reality the list of steps would be much longer than what is shown here. Also, there will probably be several different scripts for the same tool. Another script we d probably create would be to ensure that the appropriate error messages appear on the screen if the user makes a mistake or omits required information. This list of testing steps would lead the tester to purposely make an error so that the error messages would appear and therefore could be recorded and confirmed. It s not necessary to send these test scripts to the clients unless they ask for a review. It s really the agency s job to ensure that the project is tested correctly. But please do go through the scripts and make sure that the person who put them together didn t miss anything. Remember to refer back to the BRD for information on the expected functionality, and also look at comps to make sure that no additional i functionality has been added d without ih bi being captured in the BRD. 267

15 Digital Project Management Testing MODULE 10 Testing This module follows chapter 10 Testing from the book. Estimated instruction time: 2 hours 70 minutes of instruction 30 minutes of discussion 20 minutes for exercise Welcome to the module 10 of Digital Project Management, The Complete Step by Step Guide to a Successful Launch. In module 10 we will complete systems integration testing (SIT) and learn effective techniques for end to end testing. We will complete a successful round of User Acceptance Testing (UAT) without letting changes get out of control, and finally why we don t want to skip non functional testing. We may even have time for a group exercise on UAT planning and management. ASK: Before we get started, are there any questions about what we ve covered so far? 319

16 Digital Project Management Testing According to the schedule, here are our testing start dates for each tool: Search: March 27 Video Player: May 8 Contact Form: June 5 News Stories: June 12 Trip Planner: July 16 Configurator: July 17 June looks like a pretty busy month, with both the Contact Form and News Stories being ready for testing. 329

17 Digital Project Management Testing How about another exercise this one on planning out User Acceptance Testing. DO: [Distribute Exercise or refer to where it is located in the reference guide.] ASK: Who can explain what UAT is? DISCUSS: The users are the clients, and this is their opportunity to review the website before it goes live to make sure they are happy with the way everything looks and functions. The website should be 100% complete, and through SIT, so that the clients are testing a finished project. Here s the scenario. In our Jetzen case study, we re done with SIT and are now ready for UAT User Acceptance Testing. We re going to have an all team meeting to discuss UAT. Create your agenda, and then we ll discuss what your ideas are. 338

18 Digital Project Management Testing Guidelines: Guidelines refers to an instructional sheet we send to the UAT team so they can clear instructions on what they are supposed to do. It outlines what was defined during the roles and responsibilities discussion, and has all of the pertinent information in one place for people to follow along with. 350

19 Digital Project Management Cutover When people talk about cutover that word refers to the date and time that the new code is made available to the public or target audience. Other words used to capture this big moment are launch, release, or going live. If the team has a solid cutover plan in place, there shouldn t be any cause to worry. In this chapter we ll focus on learning the cutover process so that your next launch won t be too stressful. The cutover plan we teach is an Excel spreadsheet with three tabs. The first tab lists the steps to take before cutover day, The second tab lists the steps to take on cutover day, The third tab lists all of the stakeholders we ve been keeping track of since that first workshop we held with the Jetzen team months ago. It s very specific and detailed because just a tiny oversight during this process could ruin the cutover, so I suggest making a solid plan and then following it closely. 362

20 Digital Project Management Cutover Well, that s it. We ve completed every step in the Rollout Process. But there s one more thing to review. 400

21 Digital Project Management Communication Here we go again with this graphic. Which box are we in now? Of course, since there is only one box left we are in the Are we there yet box ASK: Why didn t this box come up before we launched the website? Didn t we want to know if we were there yet before we launched? LOOK FOR: At launch time we were delivering on the original business requirements for the project. After launch, we want to use our analytics reports of actual user activity to see if we are there yet. Is our website doing well against the Key Performance Indicators that the team came up with? Is this website what we thought it would be? Is it actually better or has it caused more problems? After the results are in, we go back to box number one, ask ourselves where we re at, and how to make it better. And then, we ll start the Rollout Process all over again. 401

the magazine of the Marketing Research and Intelligence Association YEARS OF RESEARCH INTELLIGENCE A FUTURESPECTIVE

the magazine of the Marketing Research and Intelligence Association vuemay 2010 5 YEARS OF RESEARCH INTELLIGENCE A FUTURESPECTIVE If You Want to Rank in Google, Start by Fixing Your Site You have an informative,