Plan Your UX Projects Smarter with Master Plans

You can learn from other disciplines.  For example, QA professionals build master test plans before starting their work.  Master planning helps you to  build end-to-end checkpoints, create hand offs with deliverables, start a timeline, plan for scope creep, and build contingency planning.  Master planning is just good business.

To help you build your master plans, consider the information usually contained in them.  In QA master plans, you will typically see this kind of information:

• Define the project stakeholders
• Define the project and its delivery dates
• Show a schedule with the UX deliverable for the project
• Explain contingencies and expectations
• Define roles and responsibilities

In many respects, the above information may seem straight-forward.  Yet, it is very important for you and your project team.

Plan the Work, Work the Plan

Beat the competition market.  Be a first mover.  Recover from a bad release.  These business pressures can make project teams to become reactive, not proactive.  Ironically, it is the common business saying of “plan the work, work the plan” that solves the reactiveness of project teams when the stakes are high from competition, your own projects, and bad releases.  

By implementing master planning, you will give your projects team a path to solving their business problem, you educate your clients on the benefits of UX, and you get ingrained earlier in the software development lifecycle.  Here is an interesting story that happened to me two years ago.

I was called into a meeting and told by the Product Manager, who has little (or no) background in user experience to perform a usability test.  Rather than launching into a discussion about the importance of engaging designers and UX professionals earlier, I wanted to keep the conversation on deliverables and time lines.  As shown earlier, the Product Manager and I worked for about 45 minutes on building a master plan.

The Product Manager understood timelines.  I spoke her language. 

After the meeting, I went into Microsoft Project and kicked out a timeline, which was used for the project.  I drafted a 15-page document called the Master Design Plan for the product.  We referenced the Microsoft Project timeline in this master plan document.

The following things happened:

• We got Executive Buy-in (see below)
• Set expectations with team members
• Timelines and deliverables were determined
• Added seven other UX deliverables (recall it was originally a single Usability Test)
• Got approval for additional resources
• Set reasonable deadlines

Most of all, this product team got out of its reactive state.  We started solving problems smarter, too.

Master Plans Get You Executive Buy-In

One of the greatest benefits of using Master Plans is you can get Executive Buy-in.  In most cases (not all), executives want to make informed decisions.  We presented the master plan to the C-level Executive for the product.  Our Executive did the following things:

• Gave the team an additional $50, 000 to do some of the suggestions in the plan
• Pushed out the Delivery Date (even with the market pressures)
• Set up meetings with us for progress reports
• Moved some other team members from other projects to help us out

The Master Plan was the artifact used throughout the discussion.  This 15-page document helped us get Executive buy-in, which is critical for your career and your projects.

Conclusions

UX professionals should use master plans, which are used by other disciplines (e.g. Development, QA).  These master plans help you to become more proactive with reactive teams, get you inserted earlier in the process, and more. In some cases, these master plans can get you valuable face time with executive for buy-in on your UX methods and practices.

Good luck!

Related articles by Zemanta

• Selling UX with Daniel Szuc (slideshare.net)
• An Event Apart: DIY UX: Give Your Users an Upgrade (lukew.com)
• UX – Beyond Design Practice (slideshare.net)
• Usability methods to improve EMRs (slideshare.net)
• An Event Apart: Anatomy of a Design Decision (lukew.com)