100+ Best Project Management Plan Tips in 2019
This blog explains 100+ Best Project Management Plan Tips with sample templates. And also explains how to start planning your new project using low-cost tools in 2019.
In this blog, you learn:
How to make sure you involve all the key people from the start of the project
What is Project Management Planning Phase
How to start planning your project using low-fidelity, low-cost tools
How to find time in your schedule to work on your responsive retrofitting project
How to maximize each person’s time throughout the project
How to define the scope of your project
How to define milestones and deadlines so your team has concrete dates to work toward
Which roll-out strategies are the most typical for responsive redesign projects
How to factor parallel site updates into your plan
The importance of keeping a record of decisions for the duration of the project
You need people to work on any project. Whether that means you will be part of a team of only two or three people or a team of dozens, you should know who will be working on the project during its different stages.
Before you delve into any kind of planning or task assignment, it is a good idea to spend some time finding out which people will and should be involved in the project. This usually is not something that is handed to you on a plate.
You need to make sure you have enough conversations and interviews to assess how the project might affect different people in different departments.
Only after you conduct this fact-finding exercise will you have enough knowledge about the structure of the team and organization to know who will be part of the project at which stages.
Involve All the Right People
Based on your initial research, write down the names of all the people who you think will be involved in the project, from beginning to end. You may have to augment this list as you go through the planning stage, but try to be as thorough as possible now. Everyone you have listed should know that they are part of the list—part of the team.
As with any other project, you should be clear about what each person’s role will be in the project, even if the description of their role will change throughout the process.
So, for each person, write a brief description of how they will contribute to the project. Will they be mainly creating the front-end code? Will they be writing content?
Are they just part of the sign-off process? Do they need to be informed about the current status of the project, but they will not actively work on or influence it?
I also find it useful to list in the same table what each person’s skills are, what they are good at and have experience at, and also what their responsibilities are—what they will have the final say in.
A user experience designer may have, for instance, the final word on the information architecture of the site or the navigation design. A front-end developer may be responsible for the coding standards, browser support, and testing.
You can start your table with the following column headings, listing one person per row:
Common roles that are part of a responsive retrofit project are the same as for any other web project. Depending on the size of the project, your team may include the following:
User experience designer
User interface designer
You also want to make sure other people outside of the usual team are included in the list if they will have any participation or say in the outcome of the project:
Quality assurance engineer
Communication and sales team
Remember that some people who might participate in the project do not have to participate in any of the planning meetings. These include the following:
Testers, whether they are external users who are formally recruited or internal people with whom you may do some guerilla-type usability testing
Consultants or anyone who may provide their experience and expertise on a given subject, but who will not effectively work on or have any say in the project
Now that you have a good overview of everyone who will be involved in the responsive project, you need to decide who will hold the project’s key role.
The next thing you need to do is make sure your project has a leader: someone who will own the project and be in charge, reminding everyone to keep on track. If you do not define a project leader, it becomes too easy to make up excuses as to why you have to delay the responsive project and prioritize other projects.
Something to keep in mind is that the project leader does not have to be the team’s project manager. Just as in many other design projects, the person who holds the lead role tends to be a senior designer or developer, quite often a user experience designer.
If I had to guess, I would say it is likely that, if you are reading this blog and following the exercises, you may be the project leader. However, you may simply be facilitating the planning of the project, but need to delegate the responsibility of leadership to someone else.
The project leader is the person who will do the following:
Make sure the project is completed
Make sure the project is delivered on time and on budget
Keep cheering the team on, even when it does not feel like you are making progress
Tie the rest of the team together, because people may not be working all together at the same time
The project leader should be someone who will work on the project, not someone who is external to the team or does not participate in the day-to-day work. But just like the other members of the team, the project leader does not necessarily have to be working on the project at all times.
When I led the responsive retrofitting of ubuntu.com, there were several periods of time when I had to work on other projects, but these had been planned and scheduled (we look into these pauses later in this section). Nonetheless, the responsive project was always part of my responsibilities.
Even when the project leader is not doing deliverable-generating work on the responsive project, it is likely that other people are. So, the project leader still needs to manage and be on top of the team’s work and what is being produced.
Everyone will have a different idea about exactly what type of effort a responsive retrofitting project involves and what it should achieve. In the planning stage, you want to make sure this subjectivity is eliminated and everyone is on the same page.
When everyone who will work on the responsive project participates in at least some of the planning meetings and workshops, they will be more invested in the project, and they will better understand why certain decisions were made.
It is harder to challenge a decision in which you had a say than a decision you had nothing to do with or the context of which you do not understand.
By the end of this stage, it is likely that more than a few compromises will have been made and that not everyone’s ideas and desires will have gone through. But you will have had the discussions necessary so that people can understand why certain decisions were made.
With limited time and resources, you have to make some tough decisions and compromises, so you do not want to run the risk of someone who joins the project at a later stage challenging every single decision that was made in the beginning—and probably made for good reason.
Keep in mind, though, that this does not mean your plan will not change at all. You may change your mind or discover that a solution you had not thought of is better than what you planned before. You should always allow for some flexibility when you find out your first idea is not the best for the project.
Another factor worth remembering is that when more senior executives are involved in the initial planning meetings and can listen to how the team is exploring the project.
Assuming your team is made up of smart, dependable professionals who create good work, of course—they tend to step away from the nitty-gritty, daily grind of the project and let everyone else do their jobs.
Again, it is important that everyone, even C-level executives, invited and encouraged to participate in the scoping and scheduling of the project if they are to (or want to) have any type of involvement in the project at later stages.
I think I know what may be going through your mind right now: “I will not really be able to get all of these people together in a room for hours on end, to plan this project—didn’t you promise that this blog offers a solution for teams with no time? What gives?”
I understand and know from my own experience how difficult it is to get lots of busy people to attend meetings that can span several hours. But I can promise you that making the effort in the beginning of the project will pay off tremendously throughout the development of your responsive site.
Because you will have time to worry about solving tricky design and development problems, rather than having to deal with politics and conflict inside and outside of your team.
Taking the time to ensure that all the right people are in the room when you kick-start your responsive retrofit project is a task in itself, one that may require a high degree of patience and waiting for the right moment when everyone is available. But if you want to get things done right from the get-go, that is what it takes.
I find that the simplest and easiest way to plan a large, complex project is to start with lots and lots of sticky notes. Working with sticky notes is a type of low-fidelity planning that allows you to move things around as many times as needed as your requirements and schedule change, and as you learn more about the project.
You can and should move the sticky notes as many times as you think you need to until you feel you have arrived at a plan that you are confident will work for your team and for the needs of your site. It is easier and cheaper to move bits of paper around than to change your design and code later.
When you are planning a project that has the potential to be extremely large and complex, involving several people throughout a long period of time, there will be a lot of small moving parts, small tasks, and ideas, that you have to group, prioritize, and schedule.
By having all the building blocks of your project easily visible in front of you, you will have a better perspective of the project’s dimensions and how much you may have to cull for each phase you want to plan.
This is a little like watching a crime show on TV. The detectives always spread all of their findings and evidence on a big wall, and they stare at the wall for hours on end, trying to find missed connections or clues.
Being able to see the entire case in front of you makes it easier to find these missing links and to think of creative, out-of-the-box solutions.
So just like those detectives, you need lots of free wall space, because sticky notes (your main tool at this stage) are known to multiply at an exponential rate. Ideally, you can find some wall space where you can keep your sticky notes and other things up for the entire duration of the responsive project.
If that is not possible, try to find ample wall space at least for the planning sessions, and make sure your findings are well documented at the end of each meeting.
You do not want to run out of sticky notes, so stock up. Do not be fooled by cheap brands, though. I recommend that you buy the real deal: 3M’s Post-it® Notes. You want to ensure that your sticky notes—that is, your ideas and your plan—do not go flying off at the faintest breath.
You want them to stick! Also get as many colors as possible, because you may want to differentiate things like types of tasks, assignees, project stages, iterations, and even different projects.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
It is likely that you will eventually have to move all the planning into a digital format. But at least in the initial stages, when ideas are being generated and you are trying to fit a complex project in with many other projects, being able to change your plan without cost and effort is important.
Depending on how your team usually works, you may want to move at least key pieces of the plan onto a digital format—which can be more easily shared with everyone—as soon as possible.
This is especially true for distributed teams, where not every team member works in the same location at all times. This digital record of your plan, tasks, and deadlines can be more or less informal, depending on what works for you.
There are several tools you can use to plan your responsive project, but some have a proven track record and are favored by many design teams.
Most of these tools offer a basic set of features and a small number of user accounts for free, but you have to pay (usually monthly, per user) to take advantage of all the features and provide access to several users.
Basecamp, currently in its third iteration, among other things, allows you to see a calendar view of all or some of your projects at once, with all their milestones and deadlines. You can also follow a project or a person’s progress on a given project, or across all projects, which can be handy.
Another useful feature added in Basecamp 3 is the ability to create automatic check-ins with the team, where you can ask anything you want on a recurring basis.
The tool you choose to use to plan your project will greatly depend on how your team works, the functionality you need, and how much you can and are willing to pay.
There are several open source project-management tools out there in addition to the ones I have outlined. If you want more control over your tool, you may want to investigate these further.
Another tool that has been around for a while is Asana. This task-management software gives you at-a-glance project status views, much like Basecamp, and also calendar and file views.
With Asana, you can create guest accounts with limited visibility of the content. It integrates with popular services such as Campaign Monitor, Dropbox, Evernote, Google Drive, Harvest, HipChat, JIRA, Slack, and WordPress.
A popular tool to take quick notes and collect inspiration and research findings is Evernote. Evernote lets you digitize physical notes, too, and create notebooks for different projects. You can also annotate documents like PDFs and see previous versions of your notes.
One of its key selling points is its comprehensive search, which searches everything in your notes, including inside images and attachments. It also provides offline access, which can be useful if you want to read through your notes anywhere, at any time.
A more recent addition to the project- and task-management tool pool is Trello. Trello works with a model of cards in columns. Its super-fast and user-friendly interface has made it into an almost-instant success among design teams.
You can create checklists within the cards and embed documents and comments. Trello supports Markdown syntax, and it integrates with services like Dropbox, Evernote, GitHub, Google Drive and Google Hangouts, MailChimp, Salesforce, Slack, and Twitter.
Finding Time in Your Schedule
If you are reading this blog, you probably work on a team that is incredibly busy, managing (or juggling) several projects at the same time, trying to plan and fit in different briefs from clients or other parts of the company.
You are also probably in charge of updating and maintaining an existing site, and you will keep having to do so even while you are working on a responsive retrofit of that very same site.
I find that the hardest part of responsively retrofitting a large site tends to be finding the time in your schedule to do so, rather than solving the several technical and design problems that will soon come your way.
But there are some processes and tools you can put to good use that will help you go beyond that familiar feeling of being faced with a project that you want to work on but that seems to not fit in your schedule.
Understand Your Calendar
Before you start adding chunks of time and dates in your calendar to work on the responsive retrofit, you need to know what your other commitments are. Using sticky notes, create a grid of the next few months, with each month or week running across the top of the wall as column headings.
Then add to the corresponding column all the deadlines when you must deliver other projects. You also need to add to the schedule the time you will be working on these projects, not just the deadlines
To make this grid a bit more complicated, but also more useful, I normally list the names of the key team members or the key disciplines (content, design, development, and so on) down the left side, as row headers.
This gives you a more granular view of the calendar and also highlights more free time within your team, because you have a per-person view, and not everyone works on every project at the same time.
When you are finished with this exercise, you will have a better idea of whether there are any free blocks of time when you can fit in the responsive project, or whether you will have to do some deprioritization of other projects so that you can work on making your site responsive.
Deprioritize Other Projects
Look at the calendar you came up with in the previous section, and identify any projects whose deadline is not set in stone or is still vague; that has an undefined or loose brief, or to which a client has not yet committed by paying or signing a contract.
Also, identify other self-initiated projects that you deem less important than converting your site to being responsive (which should be most of them). At this stage, you must be ruthless, or you will never be able to fit in a responsive retrofit.
If you do not find it tough to deprioritize some projects, you are not being tough enough with your schedule and your priorities. Once you have arrived at an updated prioritization list of projects.
And an adjusted timeline, speak to the people involved in the projects that have fallen down the priority list to explain that your team will be able to reconsider your timeline once the briefs become a little less unclear, or once other matters that make the projects unclear are resolved.
Explain that you are trying to plan a responsive redesign project, which will take priority over any loosely defined brief—and make sure to explain the benefits that working on and delivering a responsive site will bring to the entire company.
I agree that all this sounds much easier said than done: now is the time to polish those diplomatic skills.
On the flip side, by the end of this step, you should have more free blocks of time in your calendar, during which you can work on the responsive project. Now you are ready to begin filling in those spaces with the work that needs to be done.
The time you spend defining your project and your schedule will have been in vain if you are not able to then match each task to the right person, or group of people, at the right time. You want to make sure that each time one of your team members works on the project, their time and skills are being applied effectively.
For this to work, you need to develop a schedule that factors in not only each person’s main skills, expertise, and availability, but also the number of people who are necessary for a task to be completed. Some tasks require more people than others in order to be done well.
When assigning tasks to the different people on your team, consider that there are three types of tasks:
Tasks that are done by a group of people
Tasks that can be done by just one or two people
Tasks that can be done during downtime, when there are gaps in your schedule
Use Everyone at Once
Certain tasks become easier and are done much more quickly when you can all sit together and discuss the problem at hand.
By and large, when you need to generate several ideas, having a brainstorming session with a handful of people will you give you better results, more quickly, than sitting on your own and trying to come up with ideas over days or weeks.
These idea-generation sessions do not have to be lengthy to be useful. Let’s say you want to think of a more flexible solution for designing the footer of your site, which may include several links to key sections of the site, social media profile links, terms and conditions and other legal links, and so on.
In this situation, you can try to find a two-hour block during which a combination of three to five designers and developers sketch their own suggestions and everyone discusses the pros and cons of each proposed solution.
By the end of this session, you will have two or three ideas that can be then prototyped, tested, and iterated on until you have crafted a responsive footer that will work for your site.
Here are some other tasks where it is useful and more productive to have three or more people working on at a time:
Device and browser testing
Generating ideas for a responsive navigation
Generating solutions for a responsive grid
Discussing solutions for dealing with responsive images
Going through all the design patterns of your site and discussing which should be deleted or merged with other patterns
Having a session where you name your site’s design patterns
Sketching a new information architecture for your site
Other tasks where generating ideas is the key objective
Do Not Use Everyone at Once
When you defined the team to work on the responsive project, that did not mean everyone would be working on the project at all times. It is unlikely that there will be many moments when the entire team is sitting together working on the responsive project, and that is fine and expected.
Several repetitive, time-consuming tasks can be done by just one person, while everyone else can be working on other tasks or on other projects.
Anything to do with making inventories of content, pages, images, or design patterns can be done by one person. Many development tasks, especially those related to cleaning up and refactoring code, can be done by a couple of developers.
Further, much of the research into tools and solutions, and into how other people solved similar problems, can be initiated by one person, to be discussed with the wider team later.
Here are some more tasks that can be accomplished by one or two people at a time:
Inventorying design patterns
Inventorying image usage
Cleaning up markup
Cleaning up and refactoring stylesheets
Building small prototypes—for instance, to test a specific design pattern
Writing or editing copy for a new style guide, or updating an existing one
Account for Downtime
There will be times when no one on the team will be working on the project. That does not mean you can slack on making sure the project is running according to plan, though. As long as these periods of pause have been accounted for, and as long as everyone knows when they will happen, that should not be a problem.
During these pauses, the role of the project leader is important, because they must ensure that when the team returns to work on the responsive retrofit, the momentum and excitement of working on the project are replenished.
It can be dispiriting to not see progress on the work you are doing and to not be able to check things off or have the end in sight as you do them.
The project leader has to make sure the project is at the back of each team member’s mind as something they will accomplish in its own time, and as something that is moving forward in the right direction.
Now that you have carved sometime in your schedule to work on the responsive project, and you have a good overview of the time each person on your team has available during the next few weeks or months, it is time to delve into defining the scope of the project.
Keep a Tight Scope
You do not have the luxury of several large blocks of time to work on this project, so you need to focus on what you can achieve in the limited time you do have.
If you follow these steps and complete the exercises I suggest, you and your team will have a good understanding of the expected outcome of your project, what you need to do to reach that outcome, and, later, how the project will fit alongside your other projects.
Before you start these exercises, the responsive project is just an idea in everyone’s mind. Each person will have been thinking about it differently. Some people may think it does not involve much effort, whereas others may be terrified of its dimension (I suspect most of us may be in the latter group).
Once everyone’s ideas are outside of their brains and visible to the team, it will be easier to start defining the scope and timeline of the project. As you go through the steps in this section.
Be sure to take photos, write down, or record in some way all the ideas that pop up. You may want to refer to the initial stages later, and if you only capture the plan that you come up with at the end, that will not be possible.
Start with a Wish List
Once you have established the high-level goals of the project, I find that the simplest way to begin defining a more granular scope is for everyone to write on sticky notes whatever comes to mind that they would like to improve on the site, regardless of whether those things are directly related to making the site responsive.
They should write one thing per note. This is also a good way to begin breaking down a large project into small chunks. We all know that smaller tasks seem less daunting and more attainable than a single big task.
You can ask people to prepare for this exercise in advance, but leave some time for them to think about it and write down their ideas during your planning meeting.
If you want to give some instructions about what you want everyone to focus on when writing their wish list, you can say that all tasks listed should be able to be completed in a certain number of days, or in a one- or two-week sprint, for instance.
Once everyone has finished this task, have them stand up and put all the sticky notes on the wall, anywhere they want.
The next step is for everyone to help move the sticky notes around on the wall so that they are roughly gathered by topic. Do not worry if some notes are moved back and forth a few times between topics, by different people—just make sure after a certain time that the exercise is finished and everyone stops moving the notes.
You will be surprised at how what initially looked like dozens or hundreds of disparate ideas can, in fact, have many common threads.
Now it is time to organize the tasks and topics in a more structured way. Some of the tasks you define will likely be related to the project only marginally, so you can begin by moving these aside or assigning them to a different project or a following iteration of the responsive project. You can also divide tasks by degree of difficulty or completion time.
Perhaps you want to start with the quick wins in one list: the changes and updates you can do to your site that are relatively easy or not time-consuming but that would represent a step in the right direction (the responsive direction!). Move larger tasks, which may be complicated and lengthy, or may involve different teams, onto another list.
At this stage, you may want to clean up the wall and create new notes that encapsulate the main idea from each group of notes; otherwise, you will have to move a few dozen notes every time you want to move one task or idea.
Make sure, though, that you do not chuck aside ideas that sound similar to others but that are in fact distinct and should, therefore, be their own topic or task.
The next step is to begin ordering the notes by importance or, if necessary, in the chronological order in which tasks must occur. For instance, you may need to inventory all of your current design patterns before you do anything else. Or you may want to inventory all of your content or clean up your HTML.
You may feel that the most important thing to accomplish is to design and build a fully responsive navigation or to update all of your content to be more small-screen-friendly.
Whatever you and your team feel are the main priorities should be moved to the top. Some things absolutely have to occur before others tasks can be done, so make sure to capture these, too, and place them in order of priority. As for the rest, their importance is subjective, so you should expect a lot of talking and discussions during this exercise.
When someone is arguing for one task to the detriment of another, make sure their arguments are grounded on the user and/or business goals. It is hard to argue against, or for, someone who has a different opinion when their reasoning is merely based on personal preference.
It is great to work on something exciting and fun that you are passionate and happy about, but you need to be aware when that only benefits your own sense of pleasure and accomplishment and adds no value to the overall project.
As I have previously established, it is important to balance your team’s desire to make a site responsive to the other goals of the business; so it is important to be able to justify the time you will spend working on the project with sound business and user benefits, not just subjective personal likes and dislikes.
Break Down the Tasks
Some of the items you arrive at may be too large to be completed in a week or two. Some may even have to be completed in two different stages of the project. If someone listed.
For example, “Rewrite our copy to be more mobile-friendly,” you may want to divide that into two or more notes, such as “Rewrite copy of top section pages,” “Rewrite copy of the home page,” “Rewrite help pages,” and so on.
If you only have small chunks of time in between working on other projects to work on your responsive redesign, having these smaller tasks to fit in your schedule will be easier.
You should also, as a group, think about any tasks that will have to be done in relation to another note but that have not been listed. Still using the previous example, before you can rewrite any copy, you may have to hire a copywriter or define guidelines for copy and tone of voice.
The One-Hour Test
A good way to start breaking down the larger tasks in your prioritized list is to try to answer the following question: If you only had one hour, what would you do next to move the project forward?
When you have only one hour to improve something, you focus on the task that is not only the most important but also achievable in one hour—the task that will give you more bang for your buck, as they say. If you want to, or have to, you can even plan the entire project with this question in mind.
This approach means you can more easily forego nice-to-haves, embellishments, and tasks that do not add real value to the final goal, which is to make your site work beautifully across any device.
You can increase the time limit to two hours if that works best. But I do not recommend going over two hours, because then it is harder to focus on the next-most-important task that will get you closer to having a responsive site.
The scope of what you can do in two hours or more is much broader and therefore less useful when your main difficulty is deciding what to do next.
You can propose this question before you start writing your wish list so that the tasks the team comes up with are already broken down into smaller chunks. What if you make it 30 minutes? Can they think of anything that can be accomplished in that short time?
Here are some ideas of tasks you can try to complete in one hour:
Look at your site’s analytics data for specific information, such as common devices or most-visited pages.
Make an inventory of the types of images used on your site.
Assess the quality of the content in one section of your site. Is it too long to read on a small screen? Are the images adding anything to the content?
Measure the size of key landing pages.
Perform accessibility tests, such as color contrast and testing font size.
Test your site with one user.
Bear in mind, though, that there is a certain type of work that does not lend itself to being accomplished well when it is done in small blocks of time. Both designers and developers work better when they are allowed to focus on a certain task for long enough that they achieve a certain flow—or “get in the zone.”
Usually, this is desirable when designers need to create designs, when developers need to write code, or when copywriters need to, you know, write. These are the types of tasks that require a certain degree of creativity and inspiration, and sometimes of serendipity; and to create above-average results, it is important to schedule longer blocks of time that enable moments of uninterrupted work.
I find it a good idea to plan in some detail at least the first two releases of a responsive project during this planning stage. As with any other project, time frames and scopes will probably be tweaked, changed, and adapted to unforeseen circumstances.
If you and your team know which priority tasks must be completed in stage 1, you will feel more confident about leaving some tasks for the second and further releases.
You will not have time straight away to work on some of the things you would like to see fixed, but you will know that those are planned for the future and will not be forgotten.
Defining the second stage, even if loosely, and moving some of the tasks on the wall to a Phase 2 section, makes it easier to discuss which tasks should be done first. Instead of telling someone, “We will not do this,” you can say, “We will do this after these other things are completed.”
Determine What Is Out of Scope
One of the most important things to do when planning this responsive project is to list all the things you and your team will not be able to do, or fix, or even think about.
It is also very important that everyone who is working on the projector will work on it in the future knows about this list—this is another example of why it is so important for everyone who will participate to take part in the project’s initial planning stages.
I think by now we have established that you do not have the luxury of fixing everything you think is wrong with your site. The things listed under “will not fix” should be documented and shared with everyone. Some of the things other teams have left out of the first iteration of their responsive retrofit projects include these:
Updates to the information architecture
Updates to copy
Large screen layouts
Improvements to touch interaction
I am not saying that these examples should definitely be left for later stages of your project—that depends on the project’s limitations in terms of time and resources, and the needs of your site. If you do not have a list of what you will not be working on, you may have to steer your team back in the right direction and toward the right focus.
Designers and developers are opinionated folks and will have their own ideas about what should be done first. But you have spent a long time prioritizing the tasks that are most important for making your site responsive and that can realistically be accomplished in the limited time you have.
No one should be running wild with their subjective idea of what should be improved when the time is of the essence.
You should also be aware of scope creep, which may lurk around the corner once things are set in motion. It is common to come across things that turn out to be essential to do, but that was not part of the initial plan. Many more times, things pop up that are not deal breakers and that can be parked until further releases.
Before anything is added to the scope of the project, make sure to weigh its importance against all the other tasks that may have to be pushed out of the current iteration in order for these unexpected tasks to be completed. If you do not do this, the scope of your project can easily balloon.
Do Not Forget Testing
If you have not yet worked on a large responsive web design project, you may underestimate the amount of time that testing across devices and operating systems will take.
The best way to incorporate testing in your plan is to embed it every step of the way. So if you are creating a prototype of responsive navigation, allow extra time for testing.
If you are rewriting the copy on your site to be easier to read and follow on small screens, allow some time to test it on real devices before you consider that task completed.
The goal of converting your fixed-width site into a responsive one is to create an experience that is of consistently high quality across any device.
That is why it is so important to incorporate testing right from the start. At all costs, avoid leaving device testing to the end, before release. You are likely to be faced with unexpected bugs that you will have to fix at the very last minute, and they may take much longer to solve and retest than expected.
If you have a dedicated testing team, you should still make sure testing is done throughout the project, not just at the end of each release. It is important that you define the project plan alongside the testing team and align both schedules.
By the end of the steps outlined in this section, you and your team should have a much clearer, shared the idea of the effort required to reach the outcome you have defined for your responsive project and how to fit the work into your schedule.
You will have defined what success will look like at the end of the project, and the steps you need to take to get there.
All projects should have a deadline. You should be able to picture the world when the first iteration of your responsively retrofitted website is out there.
When you do not define dates for milestones and deadlines, and you rely only on your desire to see this project to fruition, you soon start to drag your heels, and other projects quickly move up your priority list.
If you usually plan frequent, small releases, you may want to try to define larger milestones in between the smaller ones, where key updates to the site are completed, such as “Release 3: All copy small screen-friendly” or “Release 5:New IA.”
Whichever is your case, make sure these milestones and release dates are defined in your schedule and in everyone’s calendars.
With a better perspective on all the other commitments, you have and how much time you have to work on the responsive project and when it should be easier to decide on a date when you think it will be possible to release the first version of your responsive site.
Even if the date you plan for release is several months in the future, it is important to define one and be sure everyone on the team is aware of it.
The date you settle on should be relatively flexible, without this fact being publicized outside of your team. However, you should move it only if there is a real emergency that needs to take priority, not if someone just deems something “urgent.”
If the CEO does not like the text color you have used on links across your sites, you may have to politely present your schedule for the next few weeks and find a time to consider the request at a later stage.
There should be a little urgency about completing this project and having something released, so do not give yourself too much leeway or pad the schedule. You want to make sure whatever you release for the world to see looks and works great, but you should not give yourself and your team more time than you normally would for any other project.
Phase 2, Phase 3 …
Ideally, at this point, you should also define a date for the release of a second phase of the project, during which you can work on less pressing, but still important, tasks.
This date will not be as set in stone like the first release date—as we all know, the further in the future a project is planned for, the more imaginative its corresponding scope and deadline can be.
But having this second phase (and possibly following phases) defined will make it less difficult to forego some of the cool things that you want to do on your project but that are not fundamental for the first phase.
A rollout strategy is very much dependent on your particular circumstances and the way you have planned your responsive project. Different types of rollout strategies include the following:
Releasing a sandboxed experimental site that lives in parallel to the existing one and that is updated often
Releasing the responsive site section by section, so old fixed-width sections coexist with new responsive ones
A complete release of a redesign of the full site
The strategy that is most suited to you will depend on the type of site you have and how your users, well, use it.
My bank’s website has been undergoing a redesign for a few years now. Online banking is a serious business, so you need to make sure your users do not make mistakes just because you have implemented a new design and things look different and have moved around. The bank’s rollout strategy started with a call to action to any customers who wanted to try the beta version of the new site.
It took a few months until all users were switched to the new design by default, and a few more months until that move was compulsory—at first, you could switch back to the old design, which I must confess I did. This is also a strategy followed by many other large websites that have millions of users every month.
The second approach, releasing the responsive site section by section, is also adopted by some large organizations. When the release is broken into sections, with each release it feels like progress is being made at good speed; this can also make it easier to plan the responsive project because each phase can be shorter.
The downside of this approach is that it may confuse visitors who go between sections; but ideally, old and new versions of the site living side by side will not happen for a prolonged period of time.
If you decide to follow the third approach—a single, full release—you will have more work to do at first, but in following iterations, you can focus on improving your new responsive site without having to go back to the old design or having to maintain two versions of the site at once.
The rollout strategy that is appropriate for your project will start to become evident as you begin planning your redesign, examining your schedule, and defining the work that needs to be done and the length of time the project will span. The choice you make will also be impacted by the way your team already works.
If you are used to releasing early and often, you may want to follow the same strategy for your responsive retrofit. Regardless of which rollout strategy, you plan to follow, I recommend that you put in place a way for users to provide feedback to the design and development team.
Taking the time to send feedback about a website can be time-consuming, so make sure it is easy and quick for someone who has something to say to say it.
Avoid asking the user to sign up for something. Ideally, you should only need an e-mail address (in case the user does not mind you following up on their comment) and the feedback itself. And remember to put in place a process that guarantees the feedback received is in fact read and acted on.
Managing Site Updates
It is very unlikely that you won’t be required to keep your existing site up to date at the same time your team is working on responsively retrofitting it. In some cases, it may be possible to pause all updates to the site during the responsive retrofit work, but this does not happen often.
The key thing to bear in mind and to avoid is the duplication of work. You are too busy to do the same thing twice more than the absolute minimum number of times, so even if you do not completely block any updates, you should limit them to only time-sensitive, high-priority ones and/or block the development of new features.
If you have the benefit of not needing to update your HTML or content management system at the same time you responsively retrofit your site, that is a good way to decrease the number of places you have to keep things in sync.
The amount of effort involved in managing site updates will be directly related to your rollout strategy and whether you are building a new content management system. I would advise you to not be too precious about keeping your demos and prototype versions of the site totally in sync with your live site.
Otherwise, you will spend more time trying to keep these various versions in sync with each other than working on making your site responsive. The next blog explores the management of content updates and editing.
Keep a Record as You Work Through the Project
The responsive retrofit of your site will probably go on for at least a couple of months, perhaps even a year or more. During this time, people will have meetings, make decisions, and change their minds many, many times, no matter how watertight you think your plan and scope are.
You should make sure a summary of these conversations, any decisions that are made, and the reasoning behind those decisions are recorded in some way.
People can be absent from discussions for several reasons: they may be on holiday, sick, working from home, or just late to work. You need to be sure the content of any discussion that produces actionable tasks and decisions is accessible to them.
Several tools are available that can make this recording easy, keep comments in a central location, notify team members about new discussions, and make sure everything is searchable.
Whichever tool you decide to use, make sure you do use it and that you and your team are thorough about keeping good meeting notes. One role of the project leader throughout the duration of the project will be to remind and nudge the rest of the team to keep good records of decisions and findings.
A popular tool used by many design teams these days is the ubiquitous messaging app Slack. Slack offers the following:
The ability to search across your entire message archive, including in attached files like PDFs and Google Docs
Fine-grained notification customization
The promise of no more e-mail
Another popular tool used by many companies large and small is the project-management app Basecamp, mentioned earlier in this blog. If you are already using a tool that works for you, stick with it.
If you are choosing a new tool, it is a good idea to talk to your team and see if there are any tools they have used successfully (or not) that would more easily integrate with their workflow. Whichever tool you choose, its main attribute should be that it fits the way you work and will be used by the entire team consistently.