Skip to main content

Author: Paul Crosby

Clear Project Goals = Better Team Relationships

Written by Paul Crosby on . Posted in Articles. 1 Comment on Clear Project Goals = Better Team Relationships

We hear those words regularly: “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 is good. When competition is within your team, it is not so good. Things go wrong, and things 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 beginning 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 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 and use a context diagram or other type of diagram. Remember a picture is worth a thousand words.

If the goal were stated as, “We are going to consolidate CRM systems.” It would cause more confusion that anything else. It does not answer the question “Why?” because the goal is not 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 to not 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 checklist. It is 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 will talk about that later when we have more details” or “We just follow the PMO process.” I have shown up to quite a few meetings where the project schedule and tasks were already determined – all without input from the team.

Milestones are not the path to success. They are just points along the journey. Keep in mind that when you reach a milestone successfully that your customers don’t say much about your success. “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 to build that new 3D printer.” Seriously I would break out a cold dead trout and slap them with it if that was said. The success here isn’t the fact there were deadlines – obviously there were deadlines and milestones – but rather the product experience by the customer.

Build the shared goal to start your projects off right. The concepts outlined in this article are a small part of Enterprise Analysis and building solid business cases for projects.

Letter from the Editor Ides of March and the Certification Quest

Written by Paul Crosby on . Posted in Articles. 3 Comments on Letter from the Editor Ides of March and the Certification Quest

The Ides of March are coming. Officially marked on the Roman calendar as March 15th as the date Julius Caesar was assassinated in Rome and which put a rather definite end to his career.

If Emperor certification existed in ancient Rome, it might have saved him from that fatal sponsor meeting. The Emperor Book of Knowledge must have an entire chapter dedicated on how not to be stabbed in the Senate. Talk about sponsor management!

Certification is a relatively new thing in our existence. For many centuries the Master, Journeyman and Apprentice system was in use. Masters of the craft would teach Journeyman and Apprentices their craft working with each other side by side for many years. Eventually the Apprentice becomes the Journeyman and the Journeyman becomes the Master. Although we don’t use these terms today in business, you can certainly see these roles being played out. In the modern world, we take certification tests to prove our knowledge after we have an enough experience in the profession.

My certification journey started off when I was a director of project managers and I was meeting with the PMO director and CIO. In this meeting, we were talking about PMBOK 1.0 and how some of these concepts could be used within our organization to drive our projects more effectively. When the subject of certification came up, we passed on the idea. A few years later I’m in a similar meeting discussing PMBOK but in this meeting my leadership turned to me and said, “I think to make yourself more credible as a leader of Project Managers, you should get this certification”.

I was a leader of other Project Managers and good at my craft of Project Management. Being asked to prove my expertise to body of folks outside the organization was terrifying. What if I failed? Did that make me a “fake” project manager? Would my leadership and team really view me differently with a certification? It was clearly a situation where failure wasn’t an option. Failing the test in my mind would mean I failed at Project Management and that I shouldn’t be a manager. I had to ensure triumph and victory.

I spent the next 3 years studying and preparing. I did not take just one PMP Prep Course – I took several. I took Project Management training classes on all subjects. I grabbed a copy of the PMBOK and read every word over several times. I got the flashcards and simulated tests. I took that simulated test over a dozen times. Every question I got wrong went on a list. I analyzed that list and dug into the materials to find the correct answer. By the time, I was finished taking the simulated tests, I was getting only 1 or 2 questions wrong.

I gathered up my work history and all the projects I worked on over the years and spent an entire Monday putting it all together. I remember clicking the submit button on the application like it was yesterday. The next day I got the confirmation. I scheduled the exam at a local exam center in 2 weeks. After I got off the call, I started sweating. Am I ready? I mean REALLY ready to take this exam?

I build my brain dump paper of all the formulas and things that I thought I would need during the exam. Two pages of glorious detail memorized. I practiced making sure I could write it all out perfectly with in 10 minutes.

Two days before the exam, I stopped. No studying, no simulated tests, no practice – nothing. I stopped thinking about it cold turkey. I took the day off work telling everyone I was going on some personal errands – I just couldn’t get enough courage to admit I was going to take my certification test. On the day of the test I got in my car and drove to the testing site. I reviewed my brain dump paper and took a deep breath. “You just have to pass”, I kept telling myself, “70% is enough to pass. You’re not going to know it all. All you can do is your best.”

I walked in, signed in and probably got frisked for contraband but I don’t remember. I sat in front of relic of a computer, took a deep breath and was given the all clear to start. In less than 3 minutes my brain dump paper was completed. I was nervous and on hyper drive at that point. I then started the computer exam. I finished in one hour, then looked up at that clock and total panicked. Did I go too fast? Am I missing everything? I went through the test again worried I totally fouled it up. I changed a few questions which every prep class out there tells you is never a good idea but I did it anyway. Over and over I went through the questions until there was 15 minutes left. Should I spend more time?

I held the mouse pointer over the finish button for several minutes just staring at it. I just couldn’t click the button. This was the point of no return. I took a deep breath and clicked. A survey popped up. “How was your experience today?” it asked cheerfully. Now you want me to take a survey? I think in some small way I lost it. I just clicked all over the page to get rid of that survey. And then it happened. After a long pause that moment I feared and dreaded was upon me. The answer to all my efforts was on the screen.

Passed.

I’m not sure but I probably floated out of that testing center. I know for certain I had a big smile on my face. It was spring and sunny out when I walked to my car. I got into my car and wore out the battery in my cell phone calling everyone I knew to tell them I passed. You couldn’t wipe that smile off my face for days.

Certification is life changing. It’s hard and requires a significant amount of time and dedication to complete. There is great reward in achieving this milestone and It has certainly helped my career many times over the years. Beware the Ides of March? Caesar didn’t make it out of his test but I certainly did.

This month’s featured articles are about certification. We hope you enjoy the great stories and journeys to get certification as told by real Project Managers and business Analysts. Don’t miss a single week’s issue!

Clear Project Goals = Better Team Relationships

Written by Paul Crosby on . Posted in Articles. 1 Comment on Clear Project Goals = Better Team Relationships

We hear those words regularly: “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 is good.

When competition is within your team, it is not so good. Things go wrong, and things 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 beginning 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 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 and use a context diagram or other type of diagram.

Remember a picture is worth a thousand words.

If the goal were stated as, “We are going to consolidate CRM systems.” It would cause more confusion that anything else. It does not answer the question “Why?” because the goal is not 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 to not 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 checklist. It is 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 will talk about that later when we have more details” or “We just follow the PMO process.” I have shown up to quite a few meetings where the project schedule and tasks were already determined – all without input from the team.

Milestones are not the path to success. They are just points along the journey. Keep in mind that when you reach a milestone successfully that your customers don’t say much about your success. “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 to build that new 3D printer.” Seriously I would break out a cold dead trout and slap them with it if that was said. The success here isn’t the fact there were deadlines – obviously there were deadlines and milestones – but rather the product experience by the customer.

Build the shared goal to start your projects off right. The concepts outlined in this article are a small part of Enterprise Analysis and building solid business cases for projects.

Letter from the Editor – Building Better Relationships & Teams

Written by Paul Crosby on . Posted in Articles. 1 Comment on Letter from the Editor – Building Better Relationships & Teams

It is February, and I am online ordering flowers for Valentine’s day and making dinner reservations for my spouse of 26 years.

This year I am dedicated to staying out of the dog house and not to forget – again. However, other than being a month for spectacular greeting card sales, the editorial team and I thought we would look at helping you improve the relationships you have with your project team, colleagues, and co-workers.

This month we kick off a new webinar and whitepaper by Bob “the BA” Prentiss. Bob is presenting “Crucial Conversations: How to Effectively Discuss What Matters Most.” This webinar looks at when to have that all-important conversation, how to prepare for it, and how to deliver a not quite so easy crucial conversation. If you missed it at the BA World and Project Summit conference last year, now is your chance to view this webinar from one of the highest ranked speakers on the conference circuit.

Gregg Brown returns to write “How to Get to an Agreement When You Disagree” following up on his keynote presentations at the BA World and Project Summit conference last year. Gregg’s practical and thoughtful advice makes for a great article on why individuals and organizations disagree and how to gain agreement in a more positive way. Check out the video at the end of his article for more insight into gaining agreement.

Every week in February will be talking about handling competitive behaviors that lead to team disruption, the different types of conflict and how to manage them, and more articles on building better relationships within your organization and project teams.

As part of building better relationships, everyone here on the editorial staff would love to hear your feedback on how we are doing to deliver the great content you have come to expect.

Stay tuned – we have a few surprises along the way for you I hope you will enjoy with great articles, thought-provoking white papers and educational webinars. Let’s take a journey together on building better relationships and teams for greater success in 2017!

Chat Soon

  • 1
  • 2