Managing Scope: Is the value of a project manager in how he/she manages scope?

No.  There is no doubt, that Project Managers have to manage scope to be successful.  However, there is a conflict of interest.  Project managers should really be focused on solving business problems and addressing business needs.  So, if this means the scope has to be expanded to include additional elements, he/she should propose expanding the scope but also negotiate increases in the project constraints, such as, time, costs/budget, quality, etc.

 

Since human nature guides individuals towards simplifying their lives, doing less, managing enough that you are sure to be successful, most project managers will work towards minimizing scope rather than expanding it.  This is the differences between a serious, strong, secure and effective project manager/leader/director and a so-so project manager who is not confident about his/her abilities and/or does not have the holistic needs of the organization or client in mind.  Pick the former and pay them well, you will reap the benefits long-term.

How Do You Implement Change from Bottom-Up?

Making change happen is challenging on its own, let alone trying to accomplish it from the bottom-up. Bottom-up change management is not easy but if done right, employee acceptance and retention is greater.

What are some of the key differences in the two methods?

Change from top-down:

• Has leadership support
• More likely to have significant resource support
• Limited overt resistance (maybe lots of passive resistance)
• Can be quickly implemented
• Useful in significant and urgent organizational changes, for example, if competition is going to run you out of business
• Effect is on enterprise-level changes trickling down to operational level processes

Change from bottom-up:  

• No executive level support or involvement
• Requires lots of selling and promotion
• Less likely to have significant resource support, you do what you can
• Lots of questions on why we are doing it and whey we are NOT doing it as an organization
• Can take more time
• Focus is on smaller, controllable processes, subcomponents to the entire organization
• Sometimes the only way to bring key changes to an organization
• Acceptance is greater with an inclusive, slower paced, employee-based approach

If managers are committed to their organizations and teams, they will attempt to improve what they see as being ineffective. That means they will initiate change at their local level even if executive-level support is not yet there. In the meantime, theses managers will promote, educate and persuade others to join in the change process. Managers of these initiatives focus on the sphere of influence and control that is directly under them. By developing their own staff and processes, they make their units more effective and efficient. With time, higher level managers will notice the changes and upstream and downstream colleagues will begin to implement at least some, if not all, of the changes that make sense for them. 

The bottom line is to do what you can under your own umbrella and approach others with simple but necessary touch-point changes so that they do not feed you poor quality. With a long-term commitment in mind, solid changes made at your local level will consume others in the organization and start to become more global.

Six Sigma and TQM are NOT Fads!

I have repeatedly heard from various managers and organizations that 6-Sigma, Total Quality Management (TQM), ISO-9000, Quality Improvement, etc. are management fads that had their time and passed on, that they are too complex and do not work. When I hear these statements, I listen to what is being said and try to (a) determine how much they know about these management techniques and methods and (b) how they define “execution” or implementation of these methods in a given organization.

First, if the understanding of these tools is basic, then the realization of their potential is going to be limited. I have worked with organizations that viewed TQM as a way to establish “Teams”. All of the organization’s resources, promotions, training and practices revolved around (a) creating teams and (b) running teams and meetings with the idea that somehow things would just get fixed by theses teams in an effective and efficient manner. All of the organization’s staff were absorbed in multiple teams dealing with a variety of issues. The reality of it is that Teams are only one of many tools in a portfolio of tools, practices and general behavior that needs to be in place for the organization to truly be practicing TQM principles.

Secondly, if the organization does not take into account that implementing these practices requires long-term commitment, not a few months, but literally years, and the organization is too impatient to get results, then they never achieve the expected big successes they have heard about. What we are talking about with these methods and practices is changing organization culture and individual behavior. Getting people to be collaborative in problem-solving and not looking at their jobs and the jobs of others as silos that if they “…just to do their piece…” takes time, commitment, energy and change of long-term attitude. The attitude needed is that my piece is dependent on the previous piece and affects the next piece and that I need to work with both my “Suppliers” and “Customers” to produce a quality product/service for the end.

I will concede that if you want something fast and simple, these methods are generally not for you. However, to attain long-term success, quality and reliable solutions, investment in 6-sigma/TQM will yield results beyond your normal operating practices, WITH TIME!

Another way to look at these methods while growing your organization’s capabilities is to use the tools and practices incrementally as needed until your organization reaches a higher degree of maturity. For instance, what I mean is, train your managers first, then some key staff, then your line workers and reinforce that we are not going to use each and every tool and method learned each and every time on every project. That you will use what is useful for a particular situation. With time and practice, there will be a slow shift towards a holistic toolset and maybe you can ultimately become certified as 6-sigma, TQM, ISO organization. One training pattern I used to develop a 6-sigma capacity in a 100+ employee organization was the following:

• Yellow-belt: train everyone in the organization on basic problem-solving (1 day)
• Green-belt: train 10-15 people (managers, project managers, team leaders, etc.) on more advanced techniques that could be used on projects (12 days). Have these people manage the projects and lead the yellow-belts.
• Black-belt: hire 1-2 black belts to act as mentors and consultants to the entire organization and support the green-belts. Lead mission-critical, high priority projects.

You Need Tools to Solve Complex Problems!

Different managers use different methods for solving business and technical problems. However, ones that succeed at getting things done in a timely and efficient manner with defined goals and objectives have skills in using tools to help them come to decisions and conclusions. This also means that you need to be educated about different tools. The more you know, the more flexible you are in using a variety of tools for various purposes. Just as you need a hammer or a screw driver to pound a nail and push a screw in, you also need management tools like how to conduct meetings, flowcharting, affinity diagramming, cash-flow projection, etc. to solve organizational problems. You can obviously pound a nail with a rock or a piece of wood or try to push a screw in using a coin, but it probably is not going to be effective or efficient.

The reason this article is posted is that I have wasted a lot of time trying to solve problems in environments led by ineffective managers who usually have one major tool that they commonly use, oral communication i.e., talking to solve complex problems. When the problem has a large number of variables and interdependencies, it is very difficult for the audience/group to keep it all together in a consistent manner. You cannot collaborate easily through just oral communication. Don’t get me wrong, oral communication is key to building relationships, persuasion and getting information out; however, it has its limits. Six Sigma, Lean, Total Quality Management (TQM), etc. did not develop because they were fads; there was intelligent design behind using them as methods to solve problems (see my article on “Six Sigma and TQM are NOT Fads!”). In addition, theses methods are rich in tools that can be helpful for dealing with a variety of situations, for instance:

• Pareto Analysis – 80/20 rule – for identifying leverage and focus areas
• Activity-Based Costing – breaking down costs across workflow steps to collect all the costs and determine problems areas
• Graphs – Time Plots/Scatter Plots, etc. – to visually map data to see patterns
• Flowcharting – for mapping out processes and data flows
• Affinity Diagramming – for organizing and grouping data
• Etc.

A good tool book reference manual to consider getting for yourself and your teams is: The Team Handbook by Peter R Scholtes, Brian L. Joiner and Barbara J Streibel.

First Step to Getting a Non-Performing Employee/Team Member on Track

Every so often you will come across an employee or team member who does not perform to your expectations. The question is how to get them to perform. The reasons for a performance failure could be many: lack of skills, unmotivated, distracted, etc.

There are many strategies that could be used to deal with these situations; however, for the sake of simplicity we will assume that the person is the right person for the job; it’s just that he/she is not doing the job you want them to do. Let’s start with some principles about human behavior:

1. Human beings are pretty smart creatures and with a little bit of time they will identify organizational and management weaknesses and might begin to exploit these. So, if a manager is not attentive to an employee’s work duties, the employee may take advantage of this and do other things e.g., browse the web, do work for themselves, etc.
2. Human beings are generally going to rank personal priorities ahead of project or organizational priorities. This is normal, it’s a matter of survival; however, under normal circumstances (e.g., not some kind of health situation), a person can focus and is hired to do a job for pay and should be focused on the job while at work rather than on personal priorities.
3. Human beings generally look for simplicity in their lives, you can even say, that in general, we tend to be “Lazy”. If the work is hard, most people will tend to avoid it, postpone it or shift it to someone else. In doing so, the work doesn’t get done or in a timely manner.

The first, and sometimes the only necessary, step to getting a non-performing employee on track is to (a) set clear expectations and (b) ensure he/she understands how he/she is being held accountable. If an employee is faltering and he/she does not get back on track through simple directional or process changes, then a candid, objective, non-threatening or non-accusatory conversation needs to occur between the manager and the employee about: (a) what is his/her role, (b) what he/she is expected to produce and by when, (c) what “Done” looks like and (d) what metrics and deliverables he/she is being evaluated against to define success. I would also ask the employee to document in a simple plan what he/she thinks the next steps are. In most circumstances, employees will reengage and respond positively and get back on track and you don’t need to go any further. For those that do not respond, the next step is to go deeper into issues and causes that have to be tackled. For instance, skill limitations could be dealt with training, reassignment of qualified staff, etc. As a last step, termination may have to be considered.

Establishing Appropriate Checks and Balances on a Project

In my opinion, it is important to separate some of the key review functions of a project from the actual performance/work of the project. What I mean is, for instance, for Information Technology (IT) projects, there are some critical needs that determine if the project and the activities/work being performed are up to standard. These needs are things like:

• Technical Architecture Review – to determine if the design is appropriate and takes into considerations the “Enterprise Perspective” of linking things to the big picture.
  
  
• Security Review – to determine if the appropriate security, privacy and audit controls are in place for the system to comply with internal policies, procedures and legislative or statutory requirement.
  
  
• Quality Assurance and Code Review – to determine if appropriate test cases have been conducted, if there is adequate levels of documentation and if the code written is understandable, maintainable, efficient, etc.

Suggestion: If you have a project director-project manager structure, where multiple project managers report to one director, you could place these critical functions under one PM and have him/her report to the director. Another option is to have a separate audit function within the organization/company with the technical experience to do this type of work either on-going on a project or on a periodic, for instance quarterly, basis.

Regardless of how you implement the functions, they are vital to ensuring things are done right. If you place these functions within a development team, they may lack the expertise or the information to link things more broadly; they may take shortcuts just to simplify their lives but hurt the long-term interests of the project and the organization, not necessarily out of negligence, just because it’s easier to do.

Starting Characteristics of a Good Project Manager

The subject of what makes a good project manager and his/her characteristics are documented broadly in almost every project management literature.  Also, the characteristics are numerous and the combination of attributes differs from person to person and the type of project that needs management.  However, based on my experience, there are some fundamental attributes that distinguishes a project manager that knows what he/she is doing and who can lead a project to success from one that goes through the right motions but results are limited or lacking.

First of all, it is important to note that a project manager has to be a leader, a take-charge person and a negotiator.  Read this short article on selecting or managing quality staff.

The additional attributes that makes a good project manager effective, at the onset, include:

• Ownership mentality - looking at the project as something that they need to do, being conscientious, and ensuring its success and feeling like it's their responsibility.
• What you don't want is someone who is going through the formal project management steps without much thought for what is really necessary and how success can be obtained.
• Is decisive but not stubborn - after having done his/her homework, a good project manager makes the right decisions and communicates it out.  However, should the information be incorrect or not all encompassing, he/she doesn't become defensive and try to push and instill his/her point of view regardless of opposing points of view.
• Develops a project plan - starts the project by planning.  He/she doesn't spend a ton of time doing analysis and trying to figure everything out before a plan can be completed; he/she sets up a structure and continuously modifies and improves on it over time.
• Starts with a context model - determines the scope and boundaries of a project by looking at the highest level of known information and the entities (people, organizations, systems, etc.) involved.  A context model sets in motion what is in and what is out and what are all the interactions and touch points of the main issue/project.
• Does not use jargon - works with simple, straight-forward and easily understandable information.
• For instance:  does not use phrases like "stakeholder analysis, subject matter expert assessment, etc."  Instead, emphasizes meeting with the right people to get the right information to move to the next step.
• Is knowledgeable about the key project metrics - knows what the budget total is and how much has been spent to date and knows the timeline and approaching critical milestones.

I am sure there are many other attributes, these serve as initial guidelines for me in determining who is the right person for the job at hand.

Project Respository - Creating a Structure for Project Documentation

When starting a project, one of the first steps is to define a project repository that can effectively collect project documents and can help the entire team in maintaining a productive team and project environment.  There are many ways to create a repository, you can use web-based collaboration tools, one such tool could be Google Docs; you can use sophisticated / developed document management and collaboration technologies, one such tool is Microsoft SharePoint; or you can use a simple directory structure.  Here I will give some examples of using a directory structure since that can be used by almost anyone in any work environment; the structure can be applied to more sophisticated solutions as well.

Regardless of what method you use, you need some fundamental guidelines for using and maintaining a quality respository:

• Guideline 1:  The project manager is the "owner" of the repository and ultimately responsible for the quality and content.  For large projects a "repository owner/manager" can be designated.
• Guideline 2:  The repository's use must be required for ALL team members.
• Guideline 3:  Some level of standards must be applied to ensure consistency.
• Guideline 4:  In each directory and sub-directory, add a "_readme.txt" file that describes how to use the sturcture.  This way the instructions to maintain consistency are easily available.

Option 1: One approach is to create a structure that mimics the existing or defined project management methodology that is used in your organization.  The benefit of this option is that documents can be stored based on the phase that you are operating under and it will reinforce the method that the project managers should use.  The drawback of this option is that the structure might not be very intuitive for people to work with.

Option 2: Another approach is to organize the documents based on a set of standard documents that are created during the project life-cycle.  The structure can be modified to include or remove certain groupings.  However, the high-level groupings / directory names would be consistent from project to project.  The benefit of this option is that it is easier for project managers to work with during the project life cycle.  The drawback can be that over time, the grouping and conventions might sway from the original intent.

A readme file, for instance, could say something like:

business_case directory is used for:

- project justification/feasibility assessment
- cost-benefit analysis or return on investment
- overall plan/timeline/etc.
- pros and cons
- decisions

Keep your naming conventions / standards simple, clear and easy to use, for instance:

1) Use all lower case letters with underscores to separate words. This will allow for easy copy/paste/publish on multiple platforms, e.g., WebServers, UNIX machines, Windows, etc.

Example:

name_qualifier

meeting_agenda_minutes

2) Keep names short and descriptive: 8 characters to 25 characters (if possible)


3) Whenever possible, add the project acronym to the file names for easy searching, retrieval and grouping.
Example:

[acronym]_[file_or_directory_name]
hr_requirements
hr_designs
hr_training

dw = data warehouse
dw_requirements
dw_rfp
dw_designs
dw_training
dw_business_case


4) For date-specific files/information (e.g., meeting agendas and minutes), use the format:

[yyyymmdd]_name
Example: 20070113_design_mtg_agenda

Whatever method works best for you, use it consistently, improve it over time and establish some simple guidelines so people know what to do and how.

What's the Most Important First Step in Starting a Project?

Q: When you are asked to do a project, what is the first key step that needs to be taken to set the project on the right course?

A: Governance - a sustainable decision-making board

There are many first things that can be done, such as, writing a charter, defining the scope, etcetera; however, projects start moving without much attention to who are all the key stakeholders and how they need to interact:

• The champion / executive sponsor - one who can make or break the project
• Project sponsor - one who really needs the project
• Project manager - one who gets it done
• Steering committee - key, responsible stakeholders who help with evaluating issues and making decisions to guide the project and the project manager
• Other stakeholders - people who are dependent or going to be seriously impacted by the new project and could through up roadblocks
• Various processes are needed too, for instance:
• defining the roles and responsibilities and clearly communicating the expectations to the people involved;
• what information to collect and report, how often i.e., status reporting;
• defining a decision-making process;
• defining a conflict resolution process, etc.

If you don't spend some time setting this all up at the beginning stages of a project, the project starts to go in various directions without good focus, you hash and rehash the same types of issues, progress is slow, you start to encounter problems throughout various phases - for example questions like these are raised: "what is the project about; what are they doing; why isn't it getting done; why aren't we involved; etc.".  Also, resourcing becomes a problem and ultimately the project manager's life becomes increasingly difficult.

What Are the Challenges with Project Management in the Government Sector?

Why is it so difficult to manage projects in government?  From my experience, I would say that the private sector and public sector fall into two groupings in terms of how you need to manage projects and expectations. In the private sector, egos are big…you need to be conscious about this or you can get in trouble. In the public sector, bureaucracy is big…you have to be patient and expect to churn; know that many decisions made are tied to some underlying political issues that may not even relate to your project.

Other specific reasons that make it difficult to manage projects in government include:

• Strategic planning and alignment is nonexistent or very limited – they either think they have it covered or don't need it,
• Usually there is no dedicated champion or one that can last for the duration of the project – leadership turnover is constant and many are political appointees so they either lack certain technical skills or are loyal to someone else's agenda or looking out for their next position,
• Governance and decision making is cumbersome and very political – lots of covering your behind and checking the "Checkers". Also, an unwillingness to make tough, risky decisions, many times making decisions through management by committee,
• The discipline of project management is non-existent or immature if it exists – formal project methodology is missing, many don’t see the value of project management, project planning is considered “cumbersome and a waste of time”; Project Management Offices (PMOs), if they exist, are hardly what you would expect, maybe 30%-50% of a mature PMO process is in place...and so on,
• Funding is limited or non-existent; some feel projects will just get done and funded by someone else,
• You can't easily define ownership or enforce accountability,
• No one really thinks of the necessary resources to support ongoing operations, support, maintenance, etc. once a program or system is put in place,
• There is tremendous weakness in execution,
• The procurement process is complicated and can results in poor decisions – sometimes too "formula driven", so if the formula doesn't take into account all the variables, then your decision is based on limited information,
• ...just to name a few issues...

The key to success on projects in government is: (a) starting with a self-driven personality, (b) patience, and (c) starting projects by establishing a sound governance process and working through all of these issues over time, systematically developing consent for project deliverables; setting realistic expectations - "under promising but over delivering".