My top 15 project discovery questions
Kicking off a new project is always challenging: Where do you start? These 15 questions will point you and your team in the right direction, and make sure important details aren't forgotten!
When I’m initially talking to a new team or a new customer it’s always challenging to know where to start. Too often, I find myself invited to a kickoff meeting where nobody has a clear plan. That wastes everyone’s time — and inevitably, just leads to more meetings as soon as everyone drifts back to their desks and starts to wonder, “what’s next?”
If you’re new, welcome to Customer Obsessed Engineering! Every week I publish a new article, direct to your mailbox if you’re a subscriber. As a free subscriber you can read about half of every article, plus all of my free articles.
Anytime you'd like to read more, you can upgrade to a paid subscription.
I like to show up prepared with my list of “project discovery questions.” If you’ve been following along in the playbook, you’ll recognize some of these: They come directly from the current state discovery activity.
But current state discovery is a more detailed analysis intended for after the project gets going. So what do we do day one, at that first exploratory meeting? How do we make a quick assessment of a project? Most of the time, I’d like to know if the project is off the rails, how big the problems are, and what kind of team I’ll be working with before committing to an engagement. With that in mind, here’s my go-to list of questions.
Project discovery questions
What’s the team organization and structure like?
Purpose: I want to expose the team dynamics. That means how many teams, and the individual composition of each team, and how they’re connected.
Why it’s important: Bottom line, I want to know if the team structure is healthy and enables “getting things done.” An ideal team is going to have a full representation of skills, resources, and knowledge so they aren’t blocked by external dependencies or downstream silos. I also want to know that the team isn’t too small or too big, both of which indicate different kinds of problems — and easily leads to follow on questions. “Interesting! Is having two project managers splitting time on a 13 person team working well for you?”
Are there well-established ways of working, methodologies and team ceremonies?
Purpose: For the most part, I’m looking to understand what methodology the organization and team prefers, and how well they’ve adopted it.
Why it’s important: Different methodologies have strengths and weaknesses. Waterfall is the right choice in some situations, and others are better suited to agile. Context is king here and warrants digging deeper into geography, specifics like Scrum versus Kanban, what sprint ceremonies are followed, and how the team goes about those activities. I’d like to know if the business is trying to compare team velocities, if scrum teams are actually co-located, and if the product owner behaves like a project manager.
When planning an iteration, generally how many hours are invested?
Purpose: To expose whether the organization thinks monolithically or agilely.
Why it’s important: There are plenty of organizations that swear up and down they are agile. Then you find out the last iteration took 100 hours to plan and it looks like a huge, monolithic release train. Naming a few things with agile-sounding names and giving project managers a new “scrum master” title does not make an organization agile.
If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!
Keep reading with a 7-day free trial
Subscribe to Customer Obsessed Engineering to keep reading this post and get 7 days of free access to the full post archives.