Does a Project Manager Need to be a Technical Expert?

Does a project manager need to be a technical expert to manage a technical project?  The answer is an unequivocal, “Maybe!”

To more fully answer this question we need to understand the primary responsibilities of the project manager on a technical project.  The Project Management Institute defines the Project Manager role as, “The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.”  Two phrases jump out of that definition, “lead the team” and “achieving the project objectives.”  Let’s examine each of those and see where that takes us.

Lead the Team

There are hundreds of definitions of team leadership.  They each emphasize various personal attributes and skills of the leader.  I am going to focus on three that I believe are very important in the project management context, trust, communication, and decision-making.

For trust to grow between a project manager and the project team, two things must exist, integrity and relationship.  The project manager must build a relationship with the team members and stakeholders and that relationship must be grounded in integrity.  If the project manager does not have a relationship with the team members, he or she must quickly develop one.  In building that relationship, the project manager and the team must be honest with each other in order to build trust.  Through that relationship building the team will come to understand the strengths and weaknesses the project manager brings to the team.

So how does technical expertise impact trust?  The project manager should not pretend to have expertise they don’t have.  When the true level of expertise is discovered by the team, they will conclude they have been lied to and that project manager will never regain their trust.  The project manager must be comfortable saying, “I don’t know.”  By the same token, with the development of a relationship based upon integrity, the team will gain confidence in the project manager. 

Communication is vital in project work, both within the team and between the team and project stakeholders.  Normally, the project manager leads the communication activities of the team. 

When a project is highly technical, the project manager must be able to communicate about technical issues and progress.  While they do not need to be the technical expert on their team, they need to obtain enough technical knowledge to communicate effectively within the team and with stakeholders.

The third element of leading the team is decision-making.  Due to the unique nature of technical projects, they are full of decision that must be made by the project manager or the project team.  These can’t be pre-determined because the decisions rely on information, designs, and data that are generated within the project.  Failure to make timely decisions on a project will lead to delays and overruns.  But of course making a bad decision can also lead to delays, overruns, and even project failure. 

If the project manager is not technical, they need to establish a clear and fair process for how technical decisions will be made. This process needs to be understood by all team members and it needs to be followed.  In some organizations, the culture prefers authoritative decision-making rather than team decision-making.  In those organizations, a technical person needs to be in the decision-making role on technical projects.    

Achieve the Project Objectives

Since we have already discussed some of the people management aspects of the project, I am going to confine the discussion on achieving objectives to the creation of an appropriate project plan and managing the risks to the project during planning and execution.  In order to have any level of confidence that objectives will be reached, a plan is needed.  However, since we are talking about technical projects, there is inherently a level of risk in the use of the technology that must be proactively managed in order to achieve the objectives.

Project plans on technical projects will typically include design activities, test activities, analysis activities, and documentation activities.  There are often numerous tasks in each of those categories.  In order to accomplish those tasks, technical expertise is required.  However, if there are team members who have the expertise and are assigned to the tasks, there is no need for the project manager to have the expertise. The larger concern is the project planning.

The creation and maintenance of a project plan is the responsibility of the project manager.  When an organization has project templates for technical projects that include estimating guidelines and lessons learned from other projects, the project manager does not need to be a technical expert.  They can rely on this information.  However, if those don’t exist, the non-technical project manager will need to rely on the team members to provide that insight.  If the team is inexperienced, they should not be assigned a non-technical manager.  If the team is experienced and the project manager is able to quickly build trust, he or she does not need to be a technical expert.

The final point of discussion is risk management.  A major portion of a project manager’s job once the plan is in place is to monitor the project to identify and resolve risk and issues that will prevent the project from achieving the objectives.  An informal survey that I did with about a dozen experienced project managers indicated that they spend two thirds of their time managing risks and issues.  Their goal is to catch and resolve them when small so that they don’t become big.

The project manager should be relying on his or her team members to identify risk issues in their area of expertise.  The project manager then helps to resolve those and seeks to identify risks or issues from outside the project along with risks or issues on integration within the project.  Technical expertise is definitely an advantage when identifying and resolving risks.  Although if the project team is experienced and there is a lessons learned database or other project histories available, a non-technical project manager can manage the project risks.

Conclusion

So what is the bottom line?  If there is an established and robust project management methodology and the project team is comprised of experienced experts, a non-technical project manager can be effective as long as they quickly build trusting relationships with the team.  If those are missing or if the organizational culture demands an authoritative project manager – they need to also have technical expertise.

Project Dashboards

Thanks to the growth of Business Intelligence, dashboards are proliferating in companies today.  Dashboards are providing real-time, or near real-time, information to managers and supervisors on virtually every business process and every product offering.  The use of dashboards by project managers is becoming common, yet there is not a corresponding improvement in project management and execution.

So why are dashboards often ineffective as a project management tool?  Is there too much information, not enough information, or the wrong information?  Do project managers lack the skills to read and understand what the dashboard is telling them, or do they lack the confidence that they can trust what the dashboard says?  Are dashboards an appropriate tool for managing projects?

To answer these questions we need to understand what a dashboard can do well and what it cannot do well.  Then we can consider how to best use it in the project environment.  Finally, we need to determine how to prepare and equip our project managers to use a dashboard.

Dashboards

A business dashboard is an information management tool used to track key business metrics and other data relevant to managing a business unit, department or process.  Often dashboard use data visualization tools to display the metrics in charts and graphs and allow drill down to underlying detail data elements. 

The dashboard metaphor is very applicable.  The driver of a vehicle does not drive by looking solely at their dashboard; rather they are watching the road and frequently glancing at the dashboard to determine if everything is operating as expected.  If the dashboard shows they are going to fast or slow they change their speed.  If it shows that they are low on fuel, they stop for a fill-up.  If the warning lights are on or a gauge is in the “red zone” it indicates a problem and they begin to take preventive and corrective action to restore the vehicle to a proper operating condition.  The same is true with business dashboards only instead of a vehicle it is a business unit, department or process. 

Think about your dashboard for a moment.  It requires real-time information to be helpful.  Showing the speed that we were traveling yesterday is meaningless.  Showing the fuel level of the vehicle from a month ago is useless information.  Likewise, the dashboard must provide information about key performance indicators to be helpful.  For instance, providing the temperature reading of the outside air temperature does not tell me if the engine is running hot.  Measuring the acceleration time from 0 to 60 mph may give you bragging rights at the drag strip, but that measure is irrelevant if I am driving across town to visit relatives.  So instead my dashboard shows fuel consumption and if I entered the address in the GPS, it shows time and mileage to my destination which are far more practical.

Project Dashboards

So what is the implication for project management?  First, the project dashboard must have real-time information.  That means we can’t wait for a weekly or monthly team meeting to update the dashboard.  Don’t get me wrong.  Those meetings can be very useful team integration and team decision-making.  But waiting for a week or a month to find there is a problem with the activities on the critical path is unacceptable.  This means that either the project team must gather at least daily to update status or there must be some other system measurement that is collected frequently and can be used to track project performance. 

Agile/Scrum projects use the first approach.  They gather every day, sometimes more often, for a scrum meeting to update their Scrum Board and Burndown Chart – which are two dashboard views for an Agile/Scrum project.  Some collaborative project management software attempts to provide real-time information through daily status reporting of project tasks by all project team members.  

When properly implemented both of these systems can work well.  However, not every project is suited to Agile/Scrum (see Blog post “Choosing the Best Project Management Methodology”).  For the other approach, setting up the baseline project plan in the project management software can be very time consuming and frequent changes are almost impossible to maintain.  Not to mention, now all the project team must be trained and disciplined to provide status on project tasks.

So what is the answer?  Forget about project dashboards?  Add people to the project team that spend all their time creating and maintain dashboard data?  How about create a pretty chart with random data we can easily measure, give it to the PMO and hope they leave us alone?  Of course none of these are palatable.  Instead, we must find a way to simplify the dashboard so it can be easily created and maintained, but still have useful information.    

Project Dashboard Metrics

Where do we start, start with the risk register.  Think about your automobile dashboard again.  If your vehicle was built during the last 30 years, it has tons of sensors embedded in it.  All of that information does not get displayed on the dashboard, only information useful to the driver while driving.  In particular, information that tells the driver if there is a problem.  So your project dashboard should provide meaningful real-time information about project risks.  Now there may not be a direct measure of risks, but often there is an indirect measure or leading indicator of a risk.

Let’s say you have resource availability as a major risk on your project.  Track the number of hours spent on project tasks by all project team members each day.  You don’t need a breakdown by task and by minute where they spent their time; just determine if they were available.  Or let’s say that a major risk is the late delivery of an item from a vendor.  Request weekly status reports until within one month, then daily status reports of the vendor’s schedule progress.  You don’t need a full vendor audit each time, just a schedule update (which you should periodically validate).  This provides an early warning of a potential delay and gives you a chance to take corrective or preventive action. 

Conclusion

The point is to determine the simplest way to get real-time data about the risk condition and place that on your dashboard.  This doesn’t overwhelm the project team with unnecessary reporting about low risk, routine activities.  Yet it provides valuable insight about the things that the project manager should be most focused upon.  Remember you are not driving the vehicle by only watching the dashboard; rather you use the dashboard to confirm that all is running well or to take corrective and preventive action.  

Five Tips for Process Improvement Projects

Many small projects are focused on improving an existing business process.  The process works but it is slow, error-prone, and creates complaints and frustration.  Other higher priority projects were ahead of it, but now it is finally time to work on that process.  Here are some tips that apply whether it is a technology/system process, and administrative process, or an operations process.  Of course, you need to do the typical project management activities of planning the scope, schedule and resources; then tracking the activities to determine if you are on plan.  But these tips are to address some things that are unique to process improvement projects. 

1. Win Supervisor Support

We have all heard about the importance of top management support for a successful change project.  Top management support is great, but even more important on a process change projects is the support of the supervisors over the process.  They are the individuals who will help you to understand the major pain points and they are the individuals who will sustain any improvements that are implemented. 

Often these individuals are not supportive of changes to the process.  They have a very parochial interest in the process – it is their job to ensure it is performing well.  They may view a project to change it as an attack on their ability or authority.  These individuals are often suspicious of the change and will actively work to undermine it.  So as you approach the change, don’t attack the old process; which will be seen as an attack on the supervisor of the process.  Rather acknowledge the benefit it has brought the business in the past and focus on how the changes will improve the performance for the new conditions that the process must operate under.

2. Fix the Customer’s Pain

Often this type of project is subject to scope creep.  There are many things that could be done to improve the process; but the project team is constrained by money and resources to only implement a few of the potential improvements.  Prioritize the potential changes in two ways.  First prioritize by the pain the process is causing to the customer of the process.  Fix the major pain points first.  When there are multiple ways to fix a pain point, then select the approach based upon the most important project constraint, either time or money.  

When you start to work on a process, the individuals in the process often have great ideas for improvement.  Many times these ideas may be an improvement from the perspective of those working in the process, but they may have no impact on the individuals or organizations that experience the result of the process.  Ensure you have addressed the customer’s pain, and then accommodate all of the other changes that you can.

3. Use Current Proven Technology

Many of the process changes today will involve some level of technology or system implementation.  A difficulty with technology for processes is that the technology changes rapidly.  About the time that you get all the bugs worked out of a new system, it is obsolete and must be replaced.  So to minimize that companies will sometimes leap to the new leading edge technology hoping that the time until obsolescence is further off.  But with this leading edge technology, there are still many elements that are not well characterized or that are discovered while doing the improvement project.  So what is the answer?  Try to use current technology that has been proven through multiple applications.

Now that is not to say you can’t use brand new technology.  However, when that is the case, the project is a higher risk project. Project estimates should be adjusted and budget and schedule reserves should be allocated to the project because there will be unexpected technical problems that must be resolved.

4. The Changed Process Must Be Simple

When creating changes to a process, you should always be looking to simplify any manual steps or personal interactions with the process.  Simple processes will run faster and with higher quality.  The principle is known as Poka Yoke, or mistake-proofing.  It is not the same as “dumbing – down” the process.  I am not suggesting that you curtail any of the performance standards or options, but rather, that you examine each step and determine if there is another way to accomplish that activity that does not require manual interactions, or that makes it easier to accomplish that step correctly.

An approach I have often used is to determine what a “standard normal” run of the process would look like.  I then do two things.  First create a screen early in the process to determine if this is a “standard normal” run, and then simplify and automate the main process for that “standard normal” condition.  The non-standard runs go through a more manual process, requiring more interactions and decisions.  This approach will accelerate and improve the quality for the “standard normal” runs.  And allow the process operators to focus on the unusual and difficult items without slowing the others.   

5. Test and Test Again

One of the biggest problems I have found with process improvement projects is the verification test run that goes flawlessly, followed by the implementation and operational runs that are a disaster.  A process improvement is not demonstrated just because you were able to do it once in a row.  A pilot run is needed.  In addition, the pilot run is susceptible to the Hawthorne Effect which means that the improvement is because everyone is watching while our best people do the work.  When the attention is gone and the average, below average, or new worker is involved in the process; the performance improvement is not to be found.

I suggest a pilot run of the process with sufficient quantity to establish “normal flow.”  If it is a customer interaction process, you should develop customer use cases that span the range of normal customer interaction.  If it uses technology, should test it with all potential operating systems or applications.  Finding the problem now while the project team is in place and can fix it is far better than finding the problems after the project is over and success has been celebrated..

Following these five tips will bias your process improvement project for success.  

Choosing the Best Project Management Methodology

Despite some claims to the contrary and the desires of senior leaders, there is no single “best” project management methodology for all situations.  At its core, project management is a process of creativity and change.  Whether it is developing a new product, building a new facility, upgrading an existing process/system, or planning your summer vacation; it is changing the existing state of things into a new and better state.  And this is why there is no one “best” methodology.  The existing state could be stable or in crisis, the new state could be clear or ambiguous, there are varying levels of constraints on time and resources, and there are varying levels of complexity of the project results and required activities. 

A project management methodology brings order into this environment.  It clarifies activities and decisions.  It sets expectations and identifies problems and issues.  A project management methodology enables proactive management rather than reactive fire-fighting as the future state is created.  But the wrong project management methodology can make things worse.  It can create confusion, frustration, delays, overruns and ultimately project failure.

There seems to be hundreds of gurus and experts touting their project management methodology as the best.  In reviewing these, there are three categories of project management methodology that emerge.  Each of these has strengths and weaknesses.  Each of these is appropriate for some types of projects and not others.  Each of these has many variations as they are uniquely applied to different projects, different industries and in different organizations.  The three are sequential/waterfall, adaptive/concurrent, and agile/scrum.

Sequential/Waterfall

This is the approach most often associated with traditional project management.  In this approach, the project starts with a clear and specific set of requirements.  A detailed project plan is created where each organization or individual is assigned a specific task that is to be done at a set time and for a set amount of resources.  As one project task completes, the results are handed to the next individual or organization in the planned sequence. 

This approach relies on the development of a detailed project plan.  The classic project management tools such as a Work Breakdown Structure (WBS), Gantt Chart, Critical Path Analysis, Responsibility Matrix, and Earned Value Analysis are ideally suited for this type of project.  These tools are used to optimize the project during the planning phase in order to meet the requirements within the best overall time or cost.

This approach is well suited for those projects where the requirements are known and stable.  It provides order and predictability to project activities.  However, it is not very flexible.  In an unstable environment or when the requirements are only general in nature and not specific.  The project manager either cannot form a plan or they must make many assumptions, some of which are sure to be wrong, in forming the plan.  Changes to the plan with this approach are often time-consuming and expensive, so this approach should not be used with a highly dynamic environment.

Adaptive/Concurrent

This is the approach that is often used with complex projects.  In this approach, a cross-functional or multi-disciplinary team manages the project through a series of phases.  As the project starts, the team is considering requirements and options to decide a framework for the project result.  The team reaches a decision and they start on the next phase.  The project progresses from phase to phase with all disciplines participating in the work concurrently and then agreeing on the project decision before moving to the next phase.  The project adapts as the team is able to use the results and conclusions from one phase to influence the activities and decisions of the later phases. 

This approach relies on a highly collaborative project team.  Rather than a detailed prescriptive project plan, the team uses key milestone decisions to guide the project activities.  The work is often iterative in nature as each of the team members builds on the solution from the preceding phase.  These projects are often managed by a series of checklists for each milestone decision point.  Project management tools that help to managed complexity such as the Network Diagram, Responsibility Matrix, and Risk Register are particularly useful with this approach.

This approach is well suited for those projects where the requirements are general in nature and the details must be determined during the course of the project.  In addition, this approach works well when cross-functional decisions are required to reach an optimal project result.  However, this approach requires a high level of interactive participatory project management.  The detailed plan is continually changing which requires a high level of project integration activities.  This approach is not appropriate for organizations that do not work well in a collaborative dynamic environment.    

   

Agile/Scrum

The agile methodologies came onto the scene in 2001.  Several agile methodologies were created for software development.  The Scrum approach has become the most widely adopted and is now used in many settings beyond software development.  This approach has provided structure to an age-old practice of putting a dedicated team on an urgent business problem to resolve it – the crisis project.  In this approach a dedicated team is assigned for a short duration to work on focused and prioritized set of requirements, known as a sprint.  The team does as much as it can in the specified time and delivers whatever it completes.  Requirements not completed within the time period are either dropped or transferred to a new project.  On larger projects, a series of sprints may be used.

This approach relies on dedicated self-organizing team to work collaboratively to complete as much as they can in a short time.  The classic project management tools are not used.  Instead, the team relies on a prioritized list of requirements and two visual control charts, a Scrum Board and a Burndown Chart to track progress. 

This approach is ideal for relatively small projects where time is critical and the scope can be flexible.  The project duration can be shortened by an order of magnitude, but it is essential that the team be fully dedicated and fully empowered to do the project work. In a highly regulated environment with externally specified requirements and extensive documentation, the benefits of this approach or lost.  Also, when the project team needs to be very large, this approach is inappropriate.

So to choose the best approach, consider your situation – both the project and the organization.  You may find the need to modify one of these a little, or even use a hybrid where one approach is used for a portion of the project and another for the remainder.  

Authority and Response-ability

“Both for practical reasons and for mathematically verifiable moral reasons, authority and responsibility must be equal - else a balancing takes place as surely as current flows between points of unequal potential. To permit irresponsible authority is to sow disaster; to hold a man responsible for anything he does not control is to behave with blind idiocy.” Robert Heinlein, Starship Troopers.

So what should a project manager do when authority and responsibility are not balanced?  Are they faced with disaster or idiocy?  How can they effectively deal with this situation – which often happens?

Authority and Responsibility

Authority and responsibility are terms that are often used interchangeably.  But they shouldn’t be.  They are very different.  Wise project managers understand this and watch for a situation where authority and responsibility are divided.  When they see it, they know they have uncovered a project risk.  Let’s explore the definition of each.

Authority deals with control.  It is the other side of the accountability coin.  If you have authority over something, you control it.  If you are accountable for something you must answer for what happened to it.  Authority cannot be shared.  Oh sure, you may say that you are sharing authority with someone else, but when push comes to shove, and disaster is happening; who do people turn to for the decisions?  That is the person with authority.

So what about responsibility?  Rather than control, this deals with causation.  Is this person “able” to elicit a “response?”  Do they have “response – ability?”  Can they initiate a process; start an investigation; or cause an interaction to occur?  Then they are responsible for the chain of events that happens.

But once a chain of events is started, the responsible person may not be able to make decisions and control what is happening.  They may not have the authority needed to manage the results of the response.  And by the same token, an individual may have the authority to manage the results of the response but lack the ability to initiate the response or prevent its initiation. In that situation, authority and responsibility are divided and you are just a step away from disaster or idiocy.

A Practical Example

Let’s put this on a practical project level.  In a new product development project, one of the core team members is told that they have the authority and responsibility to test the new product to be sure it is ready to release to customers.  The company wants the test finished as soon as possible so that they can begin to sell the new product.  As this individual is about to start the testing, they realize that the product given to them to test is a preliminary prototype and does not represent the final design.  In addition, the test requirements were established by the quality department and do not reflect the input from the voice of the customer. 

We will start with the case where our core team member has both authority and responsibility.  They are responsible for initiating the test sequence and the authority to determine that the product is ready for release to the customer.  In this situation they may determine that some of the testing would not be able to demonstrate that the new product is ready for release.  They initiate the tests that they believe are appropriate and that are relevant to the configuration of the prototype.  At the same time they demand a proper configuration of the product be provided and the final test requirements revised to align with customer needs.  They don’t complete the tests until those are available. 

If this individual had responsibility but no authority, they would start the test with the prototype and current test requirements.  They are responsible for testing, so they test as soon as possible.  They initiate a chain of events (tests) that yield test results.  They are not accountable for whether the product is ready for release to the customer.  They do not have authority in that area.  Doing that type of testing is idiocy.

If this individual had authority but no responsibility, they would demand a production-configuration product and a rewrite of the test requirements.  They would continue to send things back to the other departments until it is perfect (and it never is).  Nothing would be initiated.  They have authority to declare the product acceptable, but they are not responsible for ensuring the testing is done as soon as possible.  This will lead to a project disaster.

The Project Manager and Risk

Here is the problem for project managers; when they see a mismatch between authority and responsibility they can expect confusion, delays, and rework at that point.  The disaster of irresponsible authority can occur leading to delays, overruns, and massive rework.  The idiocy of holding a man responsible for something he can’t control leads to frustration, anger, and ultimately to unacceptable  and wasted effort.

It is for this reason that I believe that the RACI methodology is a very poor approach to use with a Responsibility and Accountability Matrix (RAM).  RACI separates the responsibility and accountability (i.e. authority) and often spreads it across multiple individuals.  RACI, which stands for Responsible, Accountable, Consult, and Inform, assigns these roles to individuals for each project deliverable or activity.  While the methodology allows one individual to hold multiple roles, it often leads to a separation of responsibility and authority.  

I prefer to use the acronym CRSI, Customer, Responsible, Support, and Inform.   Every deliverable or activity must have both a Customer and a Responsible person.  With this approach the person who is responsible should also have the authority needed to complete the deliverable or activity.   The Support and Inform roles are only used as needed.  This has the added value of emphasizing customer awareness and customer-centric activity on the project.

Don’t fall into the trap of separating responsibility and authority on your projects.  Avoid both idiocy and disaster.

Ignorance Is NOT Bliss!

Back in 1742 Thomas Gray wrote a poem that included the line, “Where ignorance is bliss; tis folly to be wise.”  That may be the case in academia (he was at Eton College) or for those who spend their time reclining in idyllic pastures.  There is often a lot of ignorance in those settings.  But that is not the case with the world of project management.  The ignorant will not stay blissful for very long on a project.  Reality quickly intervenes and then wisdom is urgently needed.

Projects – A Process of Change

This is because of the inherent instability of projects.  They are a process of change.  They are creating a new product, process, facility, or system.  They are building up or tearing down.  They are modifying, improving, adapting, or upgrading.  Projects are all about changing the status quo. And when there is change afoot, there is instability and uncertainty.  Ignorance of the change does not protect someone from the impact of the change.  Ignorance is not bliss, it is project disaster.  Wisdom is not folly, it is vital for recognizing and reacting to changes.

Now you may be thinking that the instability and uncertainty could result in a better than expected condition.  Bliss may still occur by accident.  The project may go much faster than expected.  Things may work better than expected.  The cost may be lower than expected.  But the problem with those conditions is that phrase, “than expected.”  The business is expecting a certain level of project performance.  The change that the project brings about will impact the organization.  The business leaders are aligning the rest of the business processes and systems to accommodate that change.  Finishing the project with anything other than the expected level of performance will cause a misalignment and some corresponding negative business impact.

Assume Nothing Is Certain

Wisdom is needed on projects.  Socrates said, “The only true wisdom is in knowing you know nothing.”  That is accurate for most projects.  With the inherent uncertainty of project activity, the project will not go as planned.  The project leader and project core team members must be continually monitoring project activities and deciding when and how changes should be made to the project plan.  Don’t assume that everything will happen as planned: Check on it.

This may sound like micro-management.  It is.  But it is micro-management only in the sense that you are checking frequently to understand what is happening, not that you are continually over-riding the decisions of team members or directing them on how to do their job.  This type of micro-management is a frequent pulsing of project activity to uncover roadblocks, miscommunications, misunderstandings, and project problems.  The project leader will then work to correct each of these.  

  

Pulse Meetings

I recommend the use of project pulse meetings.  These are frequent regularly scheduled team meetings.  I know, you are saying to yourself, “We already have too many meetings! I can’t add one more.”  These meetings will ultimately reduce the amount of time spent in project meetings. 

I hold project pulse meetings every day.  The meeting lasts about 10 minutes.  These meetings are not long technical discussions and status reports, these are a quick check to find problems.  My agenda for these meetings is very simple:

1. Did the tasks that were supposed to finish yesterday finish?  If not, what do you need to get them done?
2. Did the tasks that were supposed to start yesterday start? If not, what do you need to get started?
3.  For the tasks that are underway, have you uncovered any roadblocks that will prevent you from fully completing the task on time?

Typically there are only about 10 active tasks on a project.  It takes less than a minute to answer these questions for most tasks, so the meeting is done in 10 minutes.  Then the project leader works offline with the appropriate task leader(s) to understand any problem that was raised and develop a solution.

This type of Pulse Meeting lets everyone on the team know if something is ahead or behind schedule.  They also will know the major issues the project faces.  This type of proactive knowledge allows the team to act wisely.  They can decide to ride a problem out, add extra resources or attention to a problem, or change the project plan to avoid or accommodate the problem. Thanks to the Pulse Meeting, the project leadership is not ignorant of problems.  They can proactively respond to them while they are small and reduce the need for crisis intervention or project failure.

I have conducted these meetings both in a face-to-face manner when the project team was essentially co-located and in a virtual manner when the project team was distributed across multiple locations.  I set the meeting to be at the same time and place each day.  And – this is vitally important – I cap the time, usually at 10 minutes. 

I have found these to be far more effective than weekly one hour team meetings.  In those meetings, we often don’t find out about a problem until it is already 4 or 5 days old.  By then, it is often impossible to recover back to the original budget or schedule.  In addition, these often turn into a forum where each person is talking about everything they are doing, but we lose sight of whether tasks are starting and finishing on time.

Pulse Meetings pull back the veil of ignorance and allow the project leader and team members to act wisely. 

Characteristics of a Value Creator

I have heard people use the phrase, “a culture of customer-centric value creation.”   When I ask what that means, the answers become fuzzy.  So in the interest of providing a starting point to the conversation, I offer this perspective.

As I work with individuals across many industries, companies, and levels, I find that their approach to business situations can often be categorized in several ways.  I believe that two important categorizations with respect to customer-centric value creation are whether they have an internal or an external focus to their work and whether they approach their job as an employee or an entrepreneur. Let me describe each of these in a little more detail.

Internal or External Focus

Most people try to do a good job with their work.  Whether it is pride or self-preservation, they want their work to be considered acceptable.  But how are the standards of acceptable performance determined? 

A person with an external focus will be looking to their customer for those standards.  If their work is supporting the activities of a customer-facing process, their customer is the business customer.  If their work is supporting the activities of an internal process, their customer is the business unit or department that receives the output of their process.  Either way, an externally focused person is looking outside their process activity to determine acceptable performance.

A person with an internal focus will be looking to the job description, the procedures, or the checklist to determine what to do.  They do what their instructions say to do, nothing more and nothing less.  They do not concern themselves with the impact of their performance on the customers of their business process.     

Employee or Entrepreneur

For this discussion, entrepreneurism is not based upon whether someone has started a company; rather it is based upon the attitude they have about their role in the organization. Do they see themselves as on owner responsible for company success or are they an actor playing a role?

An employee sees themselves as a role or a position on an organizational chart.  They have a prescribed area of responsibility.  They have specific assets or activities for which they are responsible.  Their attitude is that they have a job to do and they will do it well.  Within their area of responsibility they are willing to act – even improvise a bit, but they will not act outside their area of responsibility without specific direction.

An individual with an entrepreneurial attitude is not focused on just their position in the organizational chart.  Rather they are aware of what is happening across the company.  They strive to improve the organization’s ability to reach its goals.  They feel personal ownership for organizational success. Wherever they see opportunities they either act to take advantage of them, or they influence others to act.

So let’s take these two characteristics and place them in a simple four-block diagram.  When we do this we begin to see patterns in the behaviours of individuals.

Risk Avoider

This is the employee with an internal focus.  Their goal is to do their job correctly, as it is defined by the organizational chart and procedures.  They often take great pride in their work.  However, they do not step outside the boundaries of their work process.  They are content with the status quo and they resist change.  I believe that this is the majority of the workforce in most companies. 

Problem Solver

This is the employee with an external focus.  Their goal is to ensure that the process in which they are involved is running smoothly.  They look beyond the requirements of their own specific activities and determine if their customer is satisfied with the results.  If the customer is not satisfied, they seek to satisfy the customer through the assets and resources that they control.  These individuals often act as the voice of the customer within the organization.

Empire Builder 

This is the entrepreneur with an internal focus.  Their goal is to increase their power and influence in the organization.  They look beyond their current position for opportunities to take on additional responsibilities.  Often this is because they believe the work is not being done well by others and that they could do it better.  When these individuals have good people skills, they are viewed as leaders in the organization.  When they do not have good people skills, they are viewed as power-hungry tyrants.

Value Creators

This is the entrepreneur with an external focus.  Their goal is to create as many satisfied customers as possible.  They are seeking to understand customer needs and interests and to provide value propositions that address those needs and interests.  They can be very disruptive in an organization because they are often advocating changes.  Internally focused individuals will often see them as a threat to the existing organization and employees will often see them as undisciplined.    

A Culture of Customer-Centric Value Creation

Based upon this model, several questions immediately arise.     

• How many people in the organization must be Value Creators to establish a customer-centric value creation culture?  100%? 50%? 10%? 
• Can you have too many Value Creators? 
• Can you convert people in the other categories into Value Creators? Training? Incentives? Coaching? 
• What, if any, operational or governance controls should be imposed on Value Creators?

I don’t have the answers to these questions.  I have not seen the inner workings of enough customer-centric value-creating organizations to discern a pattern.  But I do believe a framework like this will help us understand culture change that must take place for most organizations.