Project Management Phase 1: How Understanding Makes or Breaks Success

It is my belief that any project should start with the curiosity of what it could be, and only through musing and imagining do we determine what it should be. The idea is unaffected by preconceptions or assumptions, and could be shaped any which way.

The discovery phase of projects is my absolute favorite because there are no restrictions or limitations to the idea at this phase; at least not until the project scope and resources are defined; meaning you pick the resource the project is supported by, and those resources impose limitations.

The discovery phase is the most important phase because without understanding, the entire project is destined to fail to meet expectations… and you won’t even realize it until it’s too late.

So - I’m sharing how I perform my discovery process and hope you find it helpful.

The first thing to do is ask about a million questions.

You should know that this is only /kind-of/ an exaggeration. The number of questions to ask should come close to feeling like a million, else you’ve not properly discovered the need, implications, complications, requirements, nor true purpose to its fullest extent. The questions phase sets the stage for all future work and paths of opportunities, and if you don’t discover the bounds, actual needs, and requirements, you’re likely headed down the wrong path!

What questions should you ask? Well - all of them! I’m going to frame this example as an information management project, but the idea is applied whether you’re creating a product or a service.

Let’s start with typical questions; the 5 W’s & 1 H:

Who is the system for?

This can be the customer; but in my world there are at least two customers - the person who presents the service, and the person who uses the service. The front-end, and the back-end. The back-end customer might be multiple people or departments, depending on the information or process.

For example: Consider a web–based store/shopping experience.

• The front-end customers are the people shopping for the product.

• The back-end customer is the owner of the product.

However, collecting financial information and transactions, the back-end customer might also include a finance team. Posting items requires marketing team/product sales write-ups, so they're also a customer.

So might be the IT department because information is being exchanged over the internet, and supported by some form of compliance, which might include contracts.... See how complicated the customers get when you consider all involved?

It is not only likely, but possible to forget these customers as part of the process without probing and inquiring about all surrounding functions. Very rarely is just one person or group the customer, so don't forget how others might be involved.

This key question encourages collaboration from all involved, and engages all perspectives which could shed important light on requirements. While all customers may not need to be at the 'discussion table' every time, it would be a disservice to a project or team to not engage the surrounding individuals to understand how the solution might impact them or their processes.

What is the system for?

Expanding on this example, the store serves a purpose: To post and sell items to customers. But, is that really all?

The WHAT is not that simple. It is a collection of design concepts, logistical needs, inventory collections, transactional exchanges, and process-controlled actions. Marketing teams might say the 'what' includes the graphic and brand identity influence requirements. Accounting might say the what is a simple transaction controller.

What the system is used for can drastically change the course of the solution. This pairs the customer needs and wants with the details and obligations of how, and why.

WHAT the system is for in the perspective of each customer might be something different, and each of those needs will need to be cohesively integrated in order to prevent burden on one part of the system, or risk completely missing the purpose for certain customers.

Where does the system reside?

Now we begin to understand what needs to be accomplished, we can frame the possibilities through defining the support systems.

Hosting a custom store through something like WordPress looks very different from a store solution like Etsy; both require different knowledge and engagements, and both have restrictions or capacity limitations to consider.

Where the geo-location of customers resides may also impact your project in some way; information management has special requirements or obligations in certain countries or states (think GDPR, PII, even age-limit measures).

The where might control how the process is set-up, restrict the capabilities, and ultimately reinforce the requirements of the overall solution. There is no one right answer for where, but once decided, a lot of other bits are forced.

When does the system need to exist in full service? When does it need to be accessible to external customers?

The when guides the time frame for your journey ahead. It also guides restrictions or access requirements if necessary.

Does the store need to be available 24/7? Only on Wednesdays? Is the need immediate, or does it exist three months in the future? This vital 'W' sets the expectation for how quickly actions will have to occur, or when they need to be accessible.

Why does a new system need to be created? Why can’t an existing system be used?

Sometimes asking these questions can inform the ‘needs’ and ‘wants’ of a system, or the ‘go’/‘no-go’ intricacies of expectations.

There is a solution for nearly every problem already built on the internet somewhere, but that doesn’t mean the solution meets all of the needs or desires of the customer(s).

Finding out why those solutions don’t meet the needs is one way to ensure the project does not cause those same failed expectations. It may also provide insight to other preferences (color, navigation, ease of use, etc.).

How do customers need to engage with it?

Remembering that there is more than one customer, this step is vital to the actual programming of information and resources.

This definition would scope the actual UI and how each customer will collect, send or retrieve information. Using the earlier example of a shop, the how would guide the look and feel, as well as literal actions, or surrounding preventative measures.

These are only the beginning questions for understanding. They are the first steps towards clarity, and intent.

Being curious about the project shouldn't stop with the discovery process; every phase should come with its own discovery moments, or questions of 'why' or 'what' you're working towards. By being curious, you can prepare for the inevitable change that might occur in your project, and potentially shift towards new solutions or options because you weren't afraid to ask 'what if?' before it was too late.

Stay curious throughout the entire project. Start each phase with a moment of 'what are we actually trying to accomplish here' and dare yourself to see that applied differently, even if to justify the path you're already on! However, going into a phase with predetermined bias can negatively impact the solution, too, so balance is needed.

I challenge you to embrace uncertainty with curiosity instead of fear, and ask as many questions as it takes to gain full understanding of the entire scope of your project. Find the edges and tendrils, the intricacies and divergencies, and control them through well defined assumptions, preventative measures, and continue to ask meaningful questions which can lead to impactful outcomes.

Three take-aways:

1. Never leave a customer out of the conversation. Never assume one path is better than another unless you've traveled it before - and even then, try not to let bias inform solutions.

2. There is no such thing as a stupid question, except for the one never asked.

3. Don't leave thoughts unspoken, questions unasked, nor idea-rocks unturned.

Stay curious, friends.