The most critical part of cross-functional teams simultaneously executing on small and large projects is the right process. Proper setup and management include four key areas: team, time, tools, and process.

Earlier in this blog series, we talked about the basics in building a website and how to turn your wishes into an actual plan.

In this blog, I’ll cover the four key areas you should focus on to set your project and team up for success: team, time, tools, and process.

Team

We start with your team because it’s the most important. People write the code. People create the design. People manage customers. People that have families, lives, hobbies…

Remembering that people are the most important piece of the puzzle will keep you grounded in what matters and ensure you hit your timelines.

Having clear team roles and responsibilities is important to avoid confusion on who handles what. This means assigning someone to handle requests not related to the current project —such as support requests. If you already have a website or other digital products, this new build will not be the only thing that requires your team’s time. Having clear paths for other inbound requests will minimize the distractions (and delays) caused by managing big and small projects side by side in your sprints.

The team should include the following roles and responsibilities. Sometimes these responsibilities will be shared on one project, but it’s best to avoid if possible.

Product Owner

The product owner or (PO) leads product strategy and project management, as well as design and engineering prioritization.

Their job is to:

• Ensure the team is happy and productive
• Ensure the product plan chosen provides the optimal ROI for the business
• Ensure that all requirements are clear
• Ensure all assets required are provided when needed to hit the timeline
• Communicate with and manage stakeholders
• Set up the tools for UAT, QA, ticket tracking, asset organization, sprint planning, and stakeholder communications
• Clear the road for the team to meet the target timelines
• Ensure your team is happy and productive. This was repeated on purpose. A happy and productive team is the most important thing for product and project success.

Not sure what UAT or QA is?

UAT is short for User Acceptance Testing

QA is short for Quality Assurance.

First Comes QA
QA is done with the development and design team. The focus here is catching significant breaks in functionality or formatting. QA is meant to make sure everything is working properly before handing off for stakeholder UAT.

QA typically includes a regression test to check each feature and function detailed in the specification and previously available on the site to ensure it’s all working properly. Regression tests are a quick way to check each use case and note what passed and failed. A good regression test makes a difference between QA representing 5% and 40% of the project time.

I use Google Sheets for the regression plan and Google Forms for the reported issues. I then update the regression plan for the development and design team noting what has passed, failed and why.

Next Comes UAT

UAT is a form of QA focused on stakeholders, allowing them to go through the product or website the way they would naturally. I use Google Forms to collect feedback from stakeholders and Google Sheets to organize feedback into categories: functional, formatting, and content.

You might wonder why use so many tools to organize this information? Why not use JIRA?

• First, I want to make it easy to collect user feedback.
• Second, I want to avoid 250 JIRA tickets or Google Sheet comments.

Google forms are easy to complete on any device. JIRA is the tool for support requests and tickets for sprint planning. Prioritizing and organizing feedback directly in the regression plan or the JIRA tickets in the sprint will create a nightmare of confusing inputs. Using external tools, I can communicate with the stakeholder, make sure I understand the issue, then provide the details necessary to the dev or design team to prioritize and address each reported issue.

Technical Captain

The technical captain (or technical team lead) is in charge of the day to day management of your dev team.

Their job is to:

• Present blockers in meeting timelines to the PO (including support requests or stakeholders breaking the process)
• Present new functionality, needed or ideal, time estimates by function, and how that functionality would impact the timing
• Schedule and manage development team project planning meetings for backlog grooming, sprint planning, and daily standups
• Execute a defined aspect of the build
• Represent the development team in stakeholder meetings

Design Captain

The design captain (or design team lead) is in charge of delivery for all project design needs.

Their job is to:

• Present blockers in meeting timelines to the PO (including change requests or stakeholders breaking the process)
• Present new design or information architecture, needed or ideal, and how that functionality would impact the timing
• Schedule and manage design team project planning meetings for backlog grooming, sprint planning, and daily standups
• Execute a defined aspect of the design
• Represent the design team in stakeholder meetings

Support Captain

The support captain is in charge of managing all stakeholder and user support requests for existing sites or products.

Their job is to:

• Review and respond to all inbound support requests
• Fix any bugs in the existing site(s) or product(s)
• Communicate the status of support requests back to stakeholders and customers
• Monitor the timing of each support request (response, resolution, time waiting)
• Escalate critical bugs they cannot handle to team backlog grooming sessions

It doesn’t matter if the team is four or 40, clear roles and responsibilities are critical to meeting product release schedules.

Time

Time comes next. Time management is the simplest but most overlooked part of project planning. Tools and processes impact time management, of course, but here are a few simple practices to reduce distractions.

1. 15 Minute Meetings. Keep the meetings brief and to the point. If there isn’t a decision to be made, don’t schedule the meeting.
2. < 1 Hour of Meetings Per Day. Keep the meetings to a maximum per day. Too many meetings dull the mind, and the team needs to be alert and productive.
3. Blackout Times. Blackout times during the day for team members. Two to three-hour blocks, one in the morning and one in the afternoon. This will give them ample time to work through big problems and chunks of the project.

Tools

The tools you use should be flexible by project and team. Use what your team is comfortable with. I do not force all of the tools and processes I prefer on any team. Focus on the requirements and make the team part of the process. It’s important to be inclusive, and you’ll also learn from them.

Here is a list of the tools I use by requirement:

Requirement	Tools
Internal Communications – 1 on 1 (< 4 messages)	Slack, Instant Messenger
Internal Communications – 1 on 1 (> 4 messages)	Call, Face to Face Chat
Internal Communications – 1 to many (> 4 messages)	GoToMeeting, Face to Face Meeting
External Stakeholder Daily / Needs Communications	Email
External Stakeholder Planning Communications	GoToMeeting, Face to Face Meeting
UAT – Stakeholder Feedback	Google Forms
UAT – Feedback Organization for Team	Google Sheets
QA – Regression Test	Google Sheets
QA – Feedback Organization for Team	JIRA, Google Sheets
Sprint Planning and Monitoring	JIRA, Google Sheets
Backlog Grooming and Monitoring	JIRA, Google Sheets
Daily Standups (communications)	JIRA, Giant Whiteboard, Trello
Progress Tracking	JIRA, Google Sheets
Support Request Management & Monitoring	JIRA, Google Sheets

 

Enforcing or reinforcing the processes are a key part of the POs job. Once the project has started, for the most part, your job consists of keeping the train on the tracks and clearing the paths.

Keeping the Train on the Tracks

Daily Standups

Daily standups are your most important tool in understanding if the train will be on time and if not—what’s getting in its way. During the standups, each team member should be reporting what’s done, next, any blockers, and anything out of the process. Out of the process refers to stakeholders sending them direct messages about a change to the project or an existing product.

Review progress after daily standups to identify any barriers in meeting goals. Product and project management means paying attention to potential delays. Listen to complaints about blockers or communications issues with stakeholders. Look at what each person is working on and make sure it’s critical to this phase of the project. Many talented people work ahead. Their mind goes off to the ideal, and they forget what’s needed and who’s waiting. It’s the POs job to make sure the team is focused.

Clearing the Tracks

Clearing the tracks means being a great filter. No requests, “bugs” that aren’t really bugs, it’s your job as PO to clear as many things from the tracks as you can to eliminate clutter in the team’s slack, email, or mind.

Here are some examples of dos and don’ts that are useful for setting expectations and transparent processes for stakeholders and team members. The example is based on a company that has several websites used by their marketing and product teams.

TOPIC	PROCESS
Content	DOs: Ensure your CMS power user (PU) has been consulted first Include your CMS PU on the request Submit requests in Google Form = provide the link If questions, contact PO in Slack Questions to be answered by stakeholder What needs to be updated? Is design required? Has anyone on your team tried to update in CMS? (why/why not/result) DONTs: Submit a support ticket Communicate directly with development or design staff—they will not respond What’s a content request? Any request that will adjust text, an image, or the formatting of a text or image on the site including capitalization, bolding, or a URL.
Bugs	DOs: Ensure all of the following items are included = (Required) Steps to repeat Device + browser Screenshots or screen recording Prioritization + justification for prioritization (Remember: everything you work on is a P1 for you. However, everything can’t be a P1 for design or development.) DONTs: Communicate directly with design or development staff—they will not respond What’s a bug? A bug is a functionality that is broken such as a form not loading or a page showing a 404 error.
New Requests & New Projects	DOs: Use a form for any new requests. In this form, you want to ask for critical information to understand the nature and priority of the request. DONTs: Communicate directly with design or development staff—they will not respond What’s a new request or project? It is any new functionality for a page or the site including a new link in the navigation, a new landing page for demand gen campaigns or a new rating integration for a product review page.

 

Sharing the Load

Sharing information across sprint planning, support planning, and reporting, and project planning with the team exposes them to the details important to the success of the project. It also gives them authority in the group and experience that’s valuable to their professional development.

Team

Yes, I am repeating team. There’s nothing more important than your team.

Here are a few of the things that I do to make sure the team is happy:

1. Be inclusive. Include your team in as much of the process as they’d like. While I don’t want to drown them in meetings—if exposure to stakeholders is important to them I make sure they are included and recognized.
2. Professional development. Speak with them often about their goals and how the projects they are working on are—or are not—meeting those goals. Showing a genuine interest in their professional development is important to their productivity and loyalty to the company and you.
3. Share the load. Sharing the load across sprint planning, support planning, and reporting, and project planning with the team exposes them to the details important to the success of the project. It also gives them authority in the group and experience that’s valuable to their professional development.
4. It’s a marathon. Do everything you can to avoid 12 hour days and working weekends. That’s not sustainable, and it shouldn’t be accepted as the norm. Avoid rushed or tired work.
5. The little things. The little things matter to people. Breakfast if there’s an early day or lunch during long work weeks. Bring their favorite snacks and drinks into meeting rooms. Be thoughtful about what’s important to them.

A lot can happen once you start a project. We’ve given you the foundation for a successful build, and in my next post, I will walk you through the day to day to preparing for a commercial launch.