CLEAR goals

 The common SMART goal seems to be very well spoken of and probably crossed your ears a few time. It stands for Specific, Measurable, Attainable, Relevant, Time-based. While they might be quite useful in defining the goal, like all things, it needs an occasional update. Here steps in the CLEAR goals. 

CLEAR goals are an agile counterpart to SMART goals. It stands for Collaborative, Limited, Emotional, Appreciable, Refine-able. 


Collaborative - Who is on the team and WHY do these collaborators matter?

Limited - What are the boundaries? When do you start/stop? And to what scale is or isn't the project?

Emotional - How does this goal make a connection with you/your team? Is it meaningful? Does it provide any personal satisfaction? What of the atmosphere?

Appreciable - What is the next action? Milestone? 

Refineable - What can I anticipate changing? What may go wrong? How would you adapt?


An example that I briefly scriblbed:  

I will have lunch with my boss at Panera Bread next year to discuss my contributions to work for a raise. If it isn't granted, then we will figure out the next thing to accomplish. 


Collaborative - With my boss. We are in it together. 

Limited - Panera Bread. Lunch. Next year. 

Emotional - Discussion of contributions

Appreciable - Discussion of next steps (should it not follow through) 

Redine-able - Discussion of next steps (should it not follow through) 

With projects, the same principle applies. You are identifying the who, (what/when/where), why, next steps, and what ifs. Perhaps it is a corollary to the SMART goals, as it assumes that your goal is already SMART to begin with. Either way, a great tool to use for nay projects. 




Comments

Post a Comment

Popular posts from this blog

XP: Card, Conversation, Confirmation - The three C's

Image
  This is a technique lifted from XP (Extreme Programming).  Card On each card is enough text that identifies a requirement. Notes of priority and cost are written on it as well. They serve as tokens for requirements and are handed to developers during implementation and returned to customers when completed. Conversation  Conversations are collectively exchanges of thought between customers and programmers. It is largely verbal, but may be communicated with supplemental examples. Confirmation Confirmation, in other words, acceptance tests, are defined at the start with the customer and shown to customer at the end of the iteration to confirm the story's completion. Note that extra documentation, while seemingly helpful, hardly "confirms" anything and cannot replace acceptance tests. 
Read more

Notes: 10 Knowledge Areas of Project Management (PMBOK 6)

Image
 Notes from here  There are 10 knowledge areas, as outlined in PMBOK 6, that are to be remembered sequentially. It is presented in logical order (with exception to Stakeholders which is tacked on at the end).  Integration: In other words, you can’t ‘do’ schedule management and ignore what the impacts of that might be on people, risk, communications, cost and the rest. Scope: Knowing what the project will deliver Schedule: all about making a detailed plan to tell everyone when the project will deliver what is in the requirements. Cost: Managing project fund Quality: Although quality varies project to project and many aren't as regimented, it is important to be aware and use appropriately Resource: Working out the resources needed to get the project done Communication: Creating a communication plan and monitoring for adjustments Risk: Covers an adequate overview of managing risks  Procurement: Depending on any purchases involved, there is a lot of contracting and negotiation Stakehol
Read more

RACI Definitions

Image
Notes from site RACI is a matrix to properly organize and define stakeholders' responsibilities in the project. While there are many methods in creating these organizations, this is just one method. Definitions should be kept nearby and the charts should be clear.  Responsible: This team member does the work to complete the task. Every task needs at least one Responsible party, but it’s okay to assign more. Accountable: This person delegates work and is the last one to review the task or deliverable before it’s deemed complete. On some tasks, the Responsible party may also serve as the Accountable one. Just be sure you only have one Accountable person assigned to each task or deliverable. (Note: It might not be your PM!) Consulted: Every deliverable is strengthened by review and consultation from more than one team member. Consulted parties are typically the people who provide input based on either how it will impact their future project work or their domain of expertise on the del
Read more