Customers Have Ideas

I was talking with a friend a few days ago about start-ups and he said something that stuck out to me. "You need an idea."

The more I thought about this, the more it bothered me. What bothered me about it was the thought that the idea was something that was a prerequisite rather than an output from the company.

This thinking is one of the reasons why so many products, companies, and marketing plans miss the mark. They approach the business just like my friend thought. You need to have a product before you find the customer. This thinking is what leads people to spend countless hours thinking of an idea, building the idea, and then trying to sell the customer on the idea. Sometimes they get lucky and are able to produce something that delights the customer, but more often than not they end up launching something where they have to iterate changes into the product in order to get the customer volume required. This iteration is typically costly to the company, requiring them to spend time in engineering, and then additional marketing to help overcome the short falls of the first release. And if your product is a physical product, you could end up with inventory that you are forced to liquidate.

Instead, talk with your customers and let them give you the idea. When you decide to start a new company or launch a new product you should start with having a target customer. And not just an idea of a customer, but really draw a profile for this customer and what their traits are. Then you can start seeking them out and talking to them about their challenges. You need to try to make sure you don't lead the customer in these conversations but rather go into the conversation open to whatever the customer is saying. Take notes from your conversations and after you talk to enough people to see a pattern of similar feedback, you can begin to define who your customer will be and develop meaningful segments. These segments will give you the valuable insight on sizing and sales targets to validate if there is value in solving for their challenges. Provided there is value, you have your idea! Now you can start figuring out just how to make that idea a reality, but that is a problem for a different day.

The 6 Questions for All Projects

New project teams and young companies are constantly looking for new ways of defining roles in project teams. Whether it is to cover a skills gap or a way of improving the team dynamics, team structure is a way to shake things up. In my experience, the best way to address this is to go through the 6 questioning words and use them assign ownership and remove confusion from the newly formed or reformed team. This format has become my roles and responsibility matrix for many of the teams I have worked with over the years due to it's simplicity and ease of use.

So how does it work? I typically, lay out the questions on the white board before the meeting begins (or word doc, etherpad, or [insert fancy electronic collaboration tool of choice]) in the format below. Then at the beginning of the meeting I give the overview and what we are doing and try not to provide too much guidance as to what role goes into each category (allows for self organizing teams).

Who?

This section covers the project stakeholders and team members who are considered to be core to the team or contacts into other teams as required. 

This is your list of project participants or stakeholders, or team roster as you have seen many times before.

What?

What is this project about, What are we doing? All questions regarding what should be handled by this person/people. In other words this group is responsible for "what" is in scope.

In a technology project, this is the product manager. Ultimately the person responsible with gathering the voice of the customer.

When?

This person/people are accountable for figuring out when we need to deliver and tracking our progress relative to when we will get done. This person is typically responsible for the schedule and milestones.

The project manager is usually the person in charge of when. As the person that takes all of the resources items and puts them in the most logical order, they are best positioned to answer this question.

Where?

This section really is trying to determine the person/people responsible for the cadence and locations of team items. This is usually the one who is setting up the status meetings, meeting room, or any of those items.

Typically, this is the project manager as well. Setting up the meetings, the cadence, and the communication standards for the project.

Why?

This question is the one that trips people up the most. And the question I hear the most, why do we need to know "why"? This is important because it helps drive clarity to the "what". If there is something ambiguous in the requirements, people can sometimes come to understand what is meant because of the why. For example, Joe has a requirement for a hook hanging from the ceiling in his garage, the handyman installing the hook is thinking about using a small hook with a 5lb weight limit. This is ambiguous until you understand why the person wants the hook (to hang their 10lb bike in the garage). So the person/people listed here should be able to tell you the story of "why" the "what" is important to them.

Many times this is the same person as the person who is responsible for what. This is because who better to answer why than the person responsible for what. So typically, this is the product manager as well. But there are many times this could be a different person, so do not assume this is always the product manager.

How?

How will you be addressing the what? "What" is not the roadmap for the work but rather the destination for where we need to arrive. "How" is the route we take to get there. "How" is speaking to the way you execute to the "what". The people in this section are the ones who figure out how to do it and the ones who execute the how. 

The development team or the people who will actually do the work to make what your building a reality own answering this question. We expect them to look at What and Why and come up with the plan that they can follow to make the what a reality.

If you would like a PowerPoint template of the format used above, feel free to e-mail me and I will gladly send you one.

Empowering Teams

Empowering teams is a popular topic among managers and has been a common discussion among the agile community. Team empowerment is tied to many aspects of a successful team and project. Practice shows that empowering your team members leads to the following benefits:

• Increased Ownership
• Improved Moral
• Higher Quality
• Improved Return on Investment (ROI) for Projects
• Faster Delivery

As you can see in the Dilbert cartoon, implementation of empowered teams can be met with opposition and confusion. Even when management wants to create these empowered teams, they can struggle to figure out how to hand over the control, how much control to hand over, and accountability once the team is empowered. 

How To Transition

First, it is important to meet with the members in the organization and discuss the transition. This is important to ensure they understand what your working towards and why. Often times, training and team building exercises are used to to help drive this message home. Getting buy in from the teams is the most important piece because without it, they may not accept the responsibilities and power being given to them.

The second part of this discussion should include determining the boundaries of their empowerment. There are three common ways I see managers struggling with how to set these boundaries.

• Managers tell the team "it can decide how the budget will be used," but the manager must approve any spend. This is a poorly veiled attempt to create an illusion of control. The team feels they made a decision but really all of the control remained with the manager. This is the fastest way to stop the empowerment process. 
• Another common way that manager attempt to divide the control, is to act as a liaison to the business or customer rather than allowing the customer direct access to the team and vice versa.
• The final way I see work being divided is that the team can determine how the work is being executed, but the manager keeps control of what work is being executed. 

Although these policies may sound reasonable, every implementation of these policies that I have witnessed has resulted in issues in areas like: on time deliveries (waiting for a busy manager), transitioning, and team moral. As such, policies like these must be kept to a minimum in order for the team to truly take the responsibility that the management is trying to hand them.

Finally, once the team has been trained and the boundaries established, it is important to let the transition start immediately but remember even the change to the new model should be driven by the team, approaching the transition in the way the team feels most comfortable in.

Management of Empowered Teams

One of the most common issues I see in management of empowered teams is "meddling". Managers typically have two common concerns that leads to "meddling" in the project which undermines the empowerment of the team.

• The manager has a concern that the team will not for fill their obligations or they will exceed the timeline or budget provided to them.
• The manager is unsure of what his/her role would be if the control is handed over.

These concerns are legitimate in a traditional role, but when you empower teams you empower them to succeed or to fail. As such you need to give them the slack to come about the work in the way they see fit which may not align with your thoughts as a manager. To help a manager be more comfortable with this, there are reports and data that you can request on a regular basis. This data should be minimal and non impactful of the team. Think of raw data that you as the manager would then parse through and/or format to your liking. In agile this is most typically a list of committed stories at the start of a sprint and the burndown as the sprint progresses.

So what should the manager be doing if the team is empowered and self organizing?  Empowering teams is not easy and just like anything requires support and maintenance to keep it going once you have the team. As a manager of the empowered team, your role will shift to focus on the following:

• Removing roadblocks
• Mentoring team members
• Training and growth plans for team members
• Conflict resolution
• HR items
• Marketing team and output
• Removing non value added tasks from the team

Empowering teams may be a change from what organizations and managers are used to doing, but it is where companies need to move given the desire to flatten organizations and work in a more lean, team focused manner. 

Execution is your skill

I was talking with a relatively new but successful project manager and he said something that took me back. His comment, "I am not sure project management is for me, I mean I am just losing my skills." As I questioned the comment it was clear that he did not value the skills that he was developing compared to those skills of his previous technical role. This conversation is one I have had before and comes up frequently when we talk about how project managers contribute to the success of projects and why a project with a proper project manager is more likely to succeed. My answer:

As a project manager, Execution is your skill!

So what does execution look like?

If you go to an artist, and you ask them about a piece of work they are working on they are likely to tell you, "it is not done until it is done". How do you know when it is done? "I will just know." Well as a project manager, this is never the correct answer.

Execution is the ability to organize around a goal and lead someone (like this artist) or a team to what is considered completion (finished work). 

Execution sounds easy, but if you look at the artist example, they don't even know what the finished result will look like. And what happens if you have 30 artists with 100 pieces of work and then they need to put it all together at the end? Most of you are probably already thinking about how to break the work down. Creating a blueprint or a plan for how each of the 100 paintings will go together perhaps creating a "theme" to help guide the work to ensure that it will all go together. Perhaps you are thinking of all of the requirements gathering questions you would ask like what colors, due date, or budget. If you are thinking about any of these things, you are practicing your execution skill.

Executing is:

1. Organizing the work in a logical manner
2. Sizing the effort and understanding the requirements
3. Keeping yourself and the team focused on the end goals
4. Delivering value to the customer and business
5. Enabling the teams to succeed through any reasonable means
6. And sometimes... getting out of the team's way

What is the value of execution? 

In Ram Charan's book, "Execution: The Discipline or Getting Things Done" Ram says that, "70% of strategic failures are due to poor execution of leadership..." As a project manager, you are the leader for the project and the one affecting change in this statistic. This is your value statement to an organization.

Here are just a few of the benefits that businesses get out of executors:

1. Shorter time to market
2. Smaller but more valuable deliverables
3. Features more closely aligned with the needs of the customers
4. Less waste and rework
5. Better alignment to strategic goals

Execution is a valuable because it is how visions are brought to reality. Organizations value this because timely arrival of strategy can make or break their company and as company dynamics are changing this is becoming more valuable.

It used to be just being in a market was enough for a company, but now companies are charged with creating new markets and products. This type of thought leading work fits nicely with the artist reference above. As the creative aspects in products and business continue to grow, the need for executors will continue to grow as well. If you can come in and apply your execution skills to ensure a specific product is first to market or that a new efficiency gets into production before the competition, businesses are looking for you.

Top 10 Activities for Project Managers

In today's world, project managers are responsible for an increasing number of things. While this shows progression in the career and growth of the project managers, we need to remember the core activities that project managers are accountable for. These activities are activities important to the success of the project and of the team, however I am increasing seeing organizations prioritize reporting, data gathering, and office politics over these critical activities.

1) Act as the Communication Hub
In my opinion, communication is the most important thing a project manager can do. As the communication hub, the project manager gathers all of the relevant project and team data together and parses through it to provide a concise and clear message to the team, stakeholders, and management. Dissemination of this information is up to the project manager and the organization, but the actions of the most skilled communicators are easily verified by asking any stakeholder, "how is project X doing?" If they have to pick up the phone and call the project manager, this area needs work.

2) Collect and Review Documentation
When it comes to documentation, let's ignore the discussion of valid and necessary documentation for this blog and rather say any documentation that has been deemed "required" is necessary for the project manager to collect into a central repository and review/confirm complete. This is to say the project manager is not responsible for the content, but rather the storage and existence of the document.  Often times, documentation is pushed to the sideline in favor of delivery, when this happens the project manager should track and ensure completion prior to completing the project.

3) Facilitate Meetings
Project managers are not necessary in every discussion that occurs on the team, but it is the project managers responsibility to facilitate the meetings. Facilitation is not simply taking notes, but rather prepping an agenda, ensuring the right audience, driving the teams to value adding conversations, and a little bit of note taking at the end. Why you ask, see item 1. When a team is not communicating effectively it may become necessary for the project manager to step in and force the communication. This may be in the form of daily standups or weekly status meetings. One of the best ways for a project manager to force communication is to put the team into a meeting and FACILITATE it. Proper facilitation will also drive shorter more effective meetings, but more on that some other time.

4) Lead the Team
Leading a project team is not always easy, but it is critical that the project manager not simply drive for tasks to be completed, but really lead the team forward.

5) Ensure Follow-ups are Done
Without this activity, things "fall between the cracks" and commitments don't get met. The project manager should track these actions and make them part of the project plan. Most of these types of follow-ups are

6) Resolve Conflict
Over a long enough project, you are bound to find conflict in the team and/or with management. The project manager should take an active role in reducing and resolving this conflict.

7) Look Out for Roadblocks and Issues
Part of our role should be to identify any broken, inefficient, or ineffective processes that we encounter in our day to day. These items cause a problem and potential delays in our projects. We may not always be able to correct the inefficiency but at the very least we should be documenting it in a lessons learned. However, when possible we should be driving for correction. After all, if it is a problem for you and your project it is a problem for someone else as well.

8) Process Improvement
Project managers are in a unique position to see processes that effect delivery of a project. Sometimes process changes seem benign but when applied at the project level, result in a significant impact to the project deliverables. As such, the project manager needs to advocate process improvements from this perspective.

9) Continually Look Ahead of the Team
As the project moves through execution, a critical part of the project manager is to remove roadblocks and impediments for the team. Looking ahead will allow the project manager to remove these roadblocks before the team gets there. Think of it like this: The team is a locomotive moving down the track. If you slow it down, it takes a lot of energy (brake power) to slow the team and then it takes a lot of energy to get the team moving again. So any work a project manager is doing before the team gets there, will go a long way in keeping the momentum.

10) Act as Marketing Department for the Team and Project
Bad news travels fast, good news (or team successes) can go unnoticed. Why is that? Because when something goes wrong, someone, typically management, has to get involved to provide corrective action, whereas a success required no additional work or action by management. The project manager needs to be in front of management, customers, and stakeholders championing the successes of the team and leading the celebrations. Doing this well, increases moral, teamwork, and leads to greater outputs in the future.

I would love to hear from everyone else, what are the top critical activities you want/need to see from project managers? Project managers, what are the things you do that you feel are the most valuable? Is anyone feeling the pressure to spend time on things like office politics instead of your project? What are the things and how do you handle the request?

Driving Process Improvement as a Project Manager

The primary delay in companies today, are processes that don't align with the work being done. This happens for a variety of reasons from the process being out of date to well meaning poorly implemented changes to a process.

As a project manager, we see the effects of these ineffective, inefficient processes daily. We see these things when our projects take longer, we have dependencies where the work waits on the process or things are delayed for an artificially imposed dependency. To improve our chances of success and the success of other projects in the company, we should be identifying and working to resolve these process issues as they are identified and outside of the flow of the project.

If there is not a process improvement team inside your organization, the PMO is a great a place for this responsibility. If you work in an organization that does not have a formal PMO, I would suggest taking the initiative to spin up a pet process improvement project led by the project manager. This should be something that goes through a formal SDLC with requirements gathering, prototyping, development, and analysis after the change. Many people will talk about the DMAIC process most well know for its place in Six Sigma which is a great process, but may be overkill depending on the size of the process you are trying to improve and the maturity of your organization. As such, unless you have a formal process improvement team, committee, or initiative I recommend the approach below.

If you don't already have some areas that need improvement, start with looking at your current processes.I have found the three areas below to typically be the areas with the largest opportunity for improvement. When evaluating them, look for places that process is driving the work rather than work driving the process. For example, some organizations require code review before the code goes to testing. This process typically takes days to get on the schedule and results in the code siting in a queue and waiting since it had to be done before the code review could be scheduled. Could you adjust the process so that code review can be requested or scheduled in the future? Could we change the code review to not be a stop and wait? Perhaps the code could continue forward to the test environment and code review could happen later (this may produce technical debt).

1. Testing
1. Is your testing automated? 
2. How do you regression test?
3. Do you have a full test environment? 
4. Who executes your testing?
2. Release Management
1. How do you migration code from one environment to the next?
2. Who is responsible for production releases?
3. What is an acceptable level of bugs released to production?
4. Are there established release windows?
3. Requirements Gathering
1. How detailed do you require your requirements?
2. Do you require a phase gate before leaving requirements gathering?
3. What is your system or approach for requirement changes?

Unless you have the support of your organization and management team, I suggest that you select the single biggest value (most time saved) and focus on that for your first process improvement and only work on one at a time.

There are entire process improvement methodologies out there that you can use to execute process improvement (Six Sigma, Lean, Business Process Improvement, etc) but here is a simple step by step for your basic process improvement:

1. Select process for improvement and create a step by step process map (example)
2. Schedule a review meeting with the concerned parties and review the "as-is" process
1. Remember that some of these people may of had a role in the creation of the now out dated process, so be nice!
3. Confirm the process as accurate and then discuss each step and what is the value of the step
1. Really drive to understand: What value does that step brings to the process? 
2. Pay close attention to why each step happens in that order. 
4. Looking at the process from delivery to the down stream process as your goal, identify how you can make that happen faster. 
1. The items such as documentation are still valid, but why can't they occur after the product or item is delivered to the downstream process? 
5. Work with the team of concerned parties to re-organize the work and remove any tasks possible.
1. For example, do you have to stop and wait for an approval or can the work continue while the approval is happening? 
6. Test small scale, with a single project for a few weeks.
7. ITERATE! Don't be afraid to carve to much off and realize that you need to add some back. 
8. Once the team is comfortable with the new process, make sure it is well communicated to everyone otherwise adoption will fail. 

Glossary of Agile Terms

It was suggested that I level set some terminology before I begin writing some more of my detailed posts about Agile. As such I have put together a glossary for your use. I am going to be posting a series of Agile content so if you have any questions about what I mean with a reference you can refer back to this post and get clarity. You will find many of these terms defined in a variety of ways on the internet, but when I use them I mean the definition below. I will try to use links to these terms when appropriate in my other posts.

Agile

A software development methodology developed by Ken Schwaber and Jeff Sutherland in the mid-1990s. In short, Agile is a way to execute a project where you prioritize the highest value items of the project and work on them first. To enable this, the cross functional team works closely with a lead (product owner) from the business team, valuing the communication and relationship over a formal requirements document.

Agile Estimation

Features are estimated in terms of there size relative to one another. This is achieved by an approach known as “planning poker” that involves the whole team. Benefits of this approach include the sharing of knowledge across the team, increased consistency through whole team involvement and accuracy of

planning through track record of delivery. See also ‘Velocity’

Backlog       

A partially or completely ordered list of work items in the form of user stories or tasks.  Backlogs exist at multiple scopes in the planning onion, most notably at the levels of each product (line), each release and each sprint.  Effort remaining at any level of backlog can be tracked in the form of burn-down.  (See below.)

Burn-down

A graph of progress over time that represents either ‘Velocity’ or work effort completed.

Calendar Day

The total hours for a give day, which is 24 hours.

Daily Scrum / Daily Stand-ups

To keep the team synchronized, there is a 15-minute meeting every day. Each team member doing work answers the questions:

            What I did yesterday?

            What am I going to do today?

            Do I have any roadblocks, and what are they?

Demonstration / Sprint Close-out / Showcase

A showcase of the features developed during an iteration. This can involve product owners and other stakeholders. Serves as an opportunity to identify new features or change in priorities.

Duration

The number of work periods (not including holidays or other non-working periods) required to complete an activity of other project element. Usually expressed as workdays or work weeks.

Effort

The number of labor units required to complete something (an activity or task, a user story). Usually expressed as ideal engineering hours or days, staff hours, staff days, or staff weeks. Should not be confused with duration.

Epic

A very large user story.  Initially product features can be described using an Epic, User Story or stories.  Epic user stories are decomposed at the appropriate time so they can be estimated and accepted into a sprint.  Epic User Stories are sometimes confused with Features or Themes.  While Epic User stories go away, features persist with the product.

Feature

A feature is a tool used to segment a product.  Features add value (functionality) and address specific needs of product users and stakeholders.  Features are useful for scaling agile.  For large initiatives, a Product Owner could decide to allocate a feature or features to a particular Agile team.    Features are sometimes confused with Epic User Stories or Themes.   Epic User Stories go away once they are decomposed.  Features always remain as a way to describe a segment of the product.  It's good practice to associate every user story with a feature.

Ideal Day

The sum of all task hours spent in any given day.  The normal amount is 6 hours of time per day.

Information Radiator

A visual information radiator can be a story board, which can be created with note cards.  Each card represents a story, and has a priority, estimate, and tasks.  The minimum headings on the board should be the following:

Product Backlog

Release Backlog

Sprint Backlog

Stories in Progress with in progress tasks

Completed Stories

Accepted Stories

Burn-down chart

Release Planning Process

The release planning process is essentially concerned with populating, ranking and sizing a backlog of value-based stories for potential delivery during the release.

Retrospective

An opportunity for team members to reflect on the previous iteration and adapt according to lessons learned. This meeting should provide an open forum for discussion and communication among the team members. The only items discussed outside the team for this meeting are the ones agreed and documented. 

SCRUM

A term for a specific type of play in Rugby that is now used to describe a type of agile software development that focuses on making each iteration a mini-project wherein each iteration  holds it's own requirements gathering (sprint planning), design, test, and build. SCRUM recognizes other critical project factors such as team dynamic and explores ways to address these in the process. 

SCRUM is the most common type of Agile used today and the terms are increasing used interchangably though it should be noted that is incorrect as there are several other types of Agile.

Scrum of Scrums

A meeting in which all Scrum masters report up to one lead Scrum master a weekly update on the respective teams.  These meeting are no longer than 5 minutes per team, but can include as many a 8 teams.  A company that has many dependent projects running concurrently would use this approach in addition to the normal Scrum process

Sprint

Sometimes called an ‘iteration’, is a distinct set of time-boxed activities conducted according to its own plan and evaluation criteria, that results in the delivery of releasable product and or system features.  Typical sprint lengths are 2 weeks beginning on Wednesday ending on Tuesday.  Sprints should never be more than 4 weeks long.

Spike

A time boxed task or tasks performed by a team member with the intent of delivering enough information to estimate a story, which was not estimable before the spike was created.  More than one person can work on a spike, but the duration of the spike should not be longer than one sprint.

Story Point

A unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one.

Task  

A development activity in support of realization of a User Story within a sprint.  A good sizing for a task is something that a single team member can achieve in around half a day or less.  Sometimes longer tasks can take up to two days, but those would normally be considered oversized for most purposes.  This is where the 12 hour maximum is set as a standard.

Technical Debt

When you borrow money that you don't have to buy something today under the expectation you will have the money to repay it in the future, that is called debt. Technical debt is merely creating code or cutting some corners in the development process today under the expectation you will have more time in the future to correct this. The work that must be redone or repaired in the future was typically put in place to meet a business need (such as release schedule). This work must be completed before the project can be considered to complete. 

Theme

Themes are used for Product Road mapping, specifically at the release level.  While Features are used to describe product segments, themes are used to describe related user stories.  These stories may be associated with a single feature, but more likely cross several features or even products.  For example a product owner may decide to roadmap a themed release around security, performance, or a new user interface widget.  In these cases the high value user stories associated with each theme across all features would move to the top of the product backlog.

User Story   

The most common form of an agile requirement, which initially provides a "placeholder for a conversation" about what would be most valuable to a client stakeholder and which evolves to provide more detailed insight and objective completion criteria (including or especially test cases) as the time for its realization approaches.  A user story should take less than one iteration to realize fully and be accepted by business stakeholders via the Product Owner; see Epic User Story above.

The user story should include an estimate and a priority.  The estimate will be based on work effort, complexity and risk. User stories are typically worded as follows, "As a "role or position", I would like "the service to do something". 

Please remember that the something defined should not be technical but rather written in normal language such as "As the customer, I would like to ensure my data is protected from unethical use and hacking."

Velocity

A measure of a team's rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the sprint. It the team completes three stories each estimated at 5 story points, their velocity is fifteen. If the team completes two five-point stories, their velocity is ten.