We hear those words constantly: We need to be more competitive. Competition is good and competition is bad. When it’s your company’s product against another companies’ product it’s good. When competition is within the team things go bad and teams become less than productive. Team Members are so busy trying to sabotage and undermine each other they forget the reason they were all brought together in the first place – to make things happen. The best teams work together with common goals and objectives to be productive. It’s sort of a 3 musketeer approach: “One for All and All for One”.
A common goal that is well understood is the best way to start a project. It brings clarity to the project team members at the start of the project. In reality we start projects were ideas are not fully developed, there are competing goals and there is outright confusion as to why the project team is even in the room in the first place.
What if a project was started with a clear goal in mind? Maybe even the business value was well understood too. How about this example:
We are undertaking the consolidation of the Filbert, Dogbert and Wally CRM systems into a single CRM system because the contact center is having difficulty getting a true picture of where a customer is within the sales cycle. We need to establish a scoring system for potential customers in order to focus our contact center agents on customers who are more likely to purchase our products. This will reduce marketing costs by 50%, reduce call length times by 20% and improve our contact center agent’s ability to service our potential customers in an expedited manner. Additionally, our contact center agents will be able to see all potential and current customers in one system and avoid having to switch between multiple systems to locate a customer.
Does the paragraph above sound like a good goal? It’s pretty good because it does contain the problem statement and the business value in one paragraph. It tells a story about why the team is together. It’s also short enough to ramble off in a hallway conversation with an executive. Focus on getting a common goal that is clear to the entire team. Don’t get caught up on explaining the scope in words – try thinking outside the box a bit and use a context diagram or other type of diagram. Remember a picture is worth a thousand words.
If the goal was simply stated as “We are going to consolidate CRM systems” it would cause more confusion that anything else. It doesn’t’ answer the question “Why?”. Because the goal isn’t clearly understood the team will be confused immediately at the start of the project.
Hold on there cowboy! That goal sounds like a solution. Being specific about a goal can sound like a solution so care needs to be taken to avoid having a goal point to a specific solution. We need to be careful about how these goal statements are crafted so they don’t sound like a solution.
A task list is not a goal. A common goal is more than a list of tasks to complete or items on a check list. It’s about the journey and the destination. How you get there and take your journey as a team is as important as arriving at the destination with the desired results. Productive teams get this and start their journey together by defining the journey. “Guys HOW are we going to get there? Agile? Waterfall? Scrumban? Combinations of one or more?”.
Think about it a bit. You get assigned to a project and have that first meeting with the project team. Does the team have a conversation about the path the project will take? Does the question “How will we get there?” ever get answered? The conversation typically winds up being, “We’ll talk about that later when we have more details” or “We just follow the PMO process”. I’ve shown up to quite a few meetings where the project schedule and tasks were already determined – all without input from the team.
Deadlines are not the path to success. They are just milestones along the journey. When something successful is done your customers and clients don’t say anything about the dates. “Wow this new 3 dimensional printer is so fast” or “Look at the stuff I can do with it”. No customer has ever said “Thankfully ABC company completed design on March 30th and moved into development using the waterfall methodology”. Seriously I would break out a cold dead trout and slap them with it. The success here isn’t the fact there were deadlines – obviously there were many deadlines – but the product experience by the customer.
Build the common goal to start your projects off right. At Bob the BA, we talk about these concepts in our Enterprise Analysis and Badass Techniques workshops. Check out Bob’s blog for more good stuff on business analysis and sign up for our newsletter today.