10 Magic Questions to Make Your Project Go Right- How to Kick Ass by Kicking Assumptions

Some people are word people. They really like words. Me, I’m more of a deeds guy. But there is one word I really don’t like. That word is “assume.” It’s use screws up more promising projects and progress than just about anything I know. Most people have heard that old line about what “assume” does to people, using the components of the word to make the point. It’s dead on.

So, in my years-long quest to stomp “assume” out of every conversation, relationship, business deal and work project that I have, I’ve developed a list of 10 (more or less) key questions I want answered before and after every project or signpost. If you, your clients and your teammates all have the same answer to these questions, your chances of a successful, on-time project go way up. I often apply these questions using Basecamp, as milestones that need to be answered so a project can move forward with improved communication, workflow and expectations.

If a project will take more than a day or involves more than two people, I like to have these questions created as milestones in a Basecamp project. If you want everyone to know, add the questions as a template in your projects. When overseeing a project, I prefer to answer these questions in a conversation, but others may prefer to do it through email or some other method. Whatever works for you, but ask these questions, and get them answered. As these are basic critical thinking exercises, they take a bit more time yet the outcome is far better.

What you are doing is emulating a translation for different personality types, be in conceptual, linear adopting or changing behaviours. This delineation is best found through simple assessments Team Dimensions Profile maps the flow of assigning roles, completing tasks, and handing off tasks to other team members through the “Z Process.” In this relay process, tasks are passed from Creators to Advancers, From Advancers to Refiners, and from Refiners to Executors. Flexers fill in the gaps to keep the process moving forward. http://bit.ly/Yv8q45

Projects – What to Ask When You Start

1. What are this project’s goals for the company and for me? Why was this goal created?
2. How do we measure success? Time to finish? Resources allocated? Lowest cost?
3. What factors will help the project’s successful, on-time delivery? What will hinder it?
4. What resources (people, time, money) do you suggest? Or should I figure that out myself?
5. What are the best check-in points to monitor progress toward completion? How should we communicate with each other regarding these milestones or check-ins?
6. What will be delivered or presented at check-ins? What format would you like this task or project in?

Projects – What to Ask When You Finish

1. What are the results of the project?
2. How do those results map back to our original goals and metrics of success?
3. What was the investment of time and effort versus the budget applied?
4. How can we improve the outcome for this kind of task next time? Any lessons to be learned? I look forward to your thoughts when experiencing this process and how you can help me make it better.

I invite you to improve this process, share your thoughts and ideas. Thanks

We are living between worlds, in a great unraveling. The old maps are fire-ash and the new ones are not yet drawn. In this gap, in this vertigo of accelerating change, the most dangerous act is not dissent, but assumption. We believe we are building the same future, speaking the same language, seeing the same light on the horizon. Yet, beneath the surface of our shared spreadsheets and synchronized calendars, a thousand private realities diverge, spawning ghost-projects and stillborn futures. The failure to build a shared world before we build the thing itself is the critical error of our time, a quiet catastrophe unfolding in every Slack channel and boardroom.

I remember the specific chill of a conference room in a San Francisco high-rise, the air thick with the hum of a failing air conditioner. We were watching a demo for a project that had consumed a year of our lives and seven figures of capital. On the screen, a beautiful interface crumbled into a cascade of error messages. The silence that followed wasn't empty; it was heavy, weighted with the ghosts of a thousand unasked questions. I can still feel the smooth, useless weight of the glossy strategy document on the table, its ink a testament to a reality that had never truly existed. I can see the slight, almost imperceptible flinch of the lead engineer as he took a sip of stale water, his jaw tight.

This is not a failure of management; it is a failure of ritual. We have forgotten the liturgy of clarification. A project is a complex system, an economic and social engine designed to transmute capital and human hours into a new reality. Assumption is the entropy that pulls these systems apart. It is the grit in the gears of the machine. The questions I have learned to ask, painfully, are not a checklist. They are a protocol for reducing that entropy. They are a technology of seeing together, of weaving a shared map before we step into the wilderness. In a tokenized world where value flows at the speed of light, a misaligned vector, a single unchallenged assumption, can bankrupt a vision before it even has a name.

I have been the source of that misaligned vector. I confess, there have been times when my own desire to appear certain, to project authority, has stopped me from asking the simple, clarifying question. I have felt the cold fear of looking foolish and chosen the greater, slower-burning foolishness of proceeding in fog. I have let teams wander into the desert because I was afraid to admit I did not know the way to the water. It is a profound and humbling thing to realize that your own ego can be the most expensive item on the project budget, an unlisted liability that can sink the entire enterprise.

The map is not the territory, but you must draw it together.