You are here: Home Blogs
Project Management Blog
Blogs

Blogs (1351)

Thursday, 29 June 2017 01:01

Define Two Major Elements of Project Scope

Written by
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.28.6

Define Two Major Elements of Project Scope

Defining scope is perhaps the most important part of the initial definition and planning process. If you don’t know what you are delivering and what the boundaries of the project are, you have no chance for success. If you have not done a good job of defining scope, managing scope will be almost impossible.

Most people generally understand what scope means, but many struggle trying to actually define the scope of a project. It is easiest if you remember there are two major aspects of defining scope on your project – deliverables and boundaries.

  • The deliverables. All projects produce deliverables. (These are sometimes called the "products" produced by the project.) Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are building goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables that get turned over to your customers - not necessarily the internal deliverables produced as a part of delivering the final solution.  
  • Project boundaries. The scope boundary statements are used to define what is within the boundaries of the project and what is outside those boundaries. The key to boundary statements is that you need to have both an in-scope and out-of-scope pair. If you cannot state both in-scope and out-of-scope, it is not a true boundary statement. For example.  


    • The major life-cycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design or Construct Phases. Or perhaps your project is performing research, but you are not going to develop the results. These would be examples of using boundary statements to clearly state what your project is responsible for, and what is out of scope. 
    • The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope. Or perhaps your project is only impacting the corporate office while the field offices are out of scope.
    • The major functionality that is in scope and out of scope. This might be a good boundary if you were delivering less than full functionality. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope. Or perhaps financial reporting is in-scope for your project, but Human Resources reporting is out of scope.
Remember these two aspects of high-level scope. First - scope is defined as deliverables and boundaries. Deliverables are the things you build during the project. Boundaries are statements that describe the project in terms of in-scope and out-of-scope. 
TenStep-logo-pngAt TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.22.06

Have You Used These Five Non-Standard
Project Management Techniques?


There are multiple ways to manage and monitor your projects. Many are "standard" models you read in most columns. However, sometimes there are reasons to implement a non-standard model. Here are five examples.

1. Hands-off - Remote Control

This means that you get a sense of what is occurring on your project by reviewing the schedule, using email, or calling team members every now and then. The remote control method doesn't incorporate much face-to-face time with the team. Much of the time spent managing the project is from behind the desk and using a computer. This method works well if it is a small project or if you are managing many, many small projects at the same time. It is not a great method, but better then none at all.

2. Really Hands-off - Auto-Pilot

This is when you get a project started and let it run itself the rest of the way - as long as the project is going well. This method can be used if the team is very experienced and has worked together successfully before. In addition, you need to trust the team to re-engage with you if they have concerns or need help.

3. Hands-on - In Your Face

The "in their face" method is on the opposite side of the spectrum of the remote control method. This is when you are immersed in every detail and provide short-term direction. You can monitor the project very effectively because you know every detail about the project. Some may call this micro-managing...and they're right. But, there is sometimes a place for micro-managing. For instance, if you have a team of junior people. It also may be right for managing short-term, critical milestones - for instance at the end of a phase or end of a project.

4. Collaboration - Can't We All Just Get Along?

This method involves team management of the project. The project is managed through regular meetings, updates, and other forms of real-time communication. An example is an agile team where there is a group of peers working together rather than a top-down hierarchical approach. This can also work if your team is working for the first time in uncharted territory. The team may work collaboratively to discover the nature of the project as you progress.

5. Default Management - The Assumptive Close

An assumptive close is when someone assumes you have already decided something - when you have not. For example, a car salesperson may ask if you would like to buy a car in red or black color - even though you have not said you would buy the car yet. This may be appropriate when people will not make decisions since it pushes people down a path. For example, rather than ask whether a sponsor agrees with a scope change request, you can list two possible outcomes of the scope change and ask the sponsor which he prefers.
..
None of these models above is totally by-the-book. However, there may be circumstances when they may be appropriate. The key is to recognize the risks associated with these approaches, and implement them purposefully - not as an excuse for lazy or sloppy project management. 
TenStep-logo-pngAt TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(0 votes)
This content is from the TenStep weekly "tips" email dated 2017.21.6

Use a Diverse Team to Gain Broader Perspective on Projects

Hiring the best candidates is one on the most important aspects of the Human Resources organization. Hiring a "diverse" team simply means you have a group of people with different backgrounds, experiences and personalities. Organizations try to hire a diverse workforce, which in turn results in diverse project teams. There are really two arguments for the business case for diversity.  The first is basic fairness and the second is the long-term business value associated with a diverse workforce.

Let’s start with the matter of basic fairness.  A company’s hiring objective is to always find the best person to fill an opening. But what does it mean to be the “best” candidate? Left to their own devices, a hiring manager tends to rate a person’s qualifications using his own background as a measuring stick.  After all, if a manager has a certain background and ended up in the position he is in today, doesn’t it make sense to look for those same traits in another person? This can tend to result in candidates with a similar look and background to themselves.

Companies, especially large ones, have tried to get away from this natural bias by standardizing the recruiting and hiring process in a way that allows each candidate to be judged based on the same set of criteria. The goal of the standard process is simply to ensure the most qualified candidate is hired. 

The second objective of a diverse workforce is to gain real business value for the company. Society as a whole is diverse and companies exist and sell products in this diverse marketplace. Companies have discovered that a diverse workforce translates into being able to prosper in a diverse marketplace for a couple reasons.

  • Exploiting the marketplace.  It is hard, if not impossible, to effectively reach a diverse marketplace without a diverse staff. You need people with diverse backgrounds to be able to thrive in a diverse marketplace. 
  • Making better decisions.  People with the same types of backgrounds have a tendency to think alike and this can affect the decisions they make.  Managers need a diverse set of opinions to make the best strategic and tactical decisions.  Some people can be very creative, but it is hard to be creative in areas where you have no background or context.  Having a diverse team helps drive better company decisions in a diverse world. 
Acquiring the project team is one of the responsibilities of a project manager. Sometimes this leads to hiring decisions. This discussion on diversity will help you understand why most companies feel that hiring a diverse workforce is important.

It is worth stating again that a focus on diversity does not mean that you hire inferior candidates. It is really focused on removing any conscious or unconscious biases so that the best candidate can, in fact, be hired.

TenStep-logo-pngAt TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com
Rate this item
(1 Vote)

392Click Here to Listen to the Interview: http://bit.ly/2s3LsEJ
Read More: http://bit.ly/PMPodcast392

My goal of having these show notes on the website is to give a quick and concise introduction of the podcast topic and to tell you what you can expect to learn from it. Sometimes I am right on point and sometimes I’m a little more vague.

And tomorrow, when you are back at the office working on your project requirements your goal will be to correctly and succinctly describe the requirements for that project your company is going to launch. The big difference here is that your descriptions have to be 100% on point. You cannot afford to be vague, because requirements that can be misinterpreted is a sure-fire way to doom your project. So what can you do to improve your requirements?

The problem of poorly written, ambiguous, and inconsistent requirements is something that Jordan Kyriakidis (https://www.linkedin.com/in/jordankyriakidis/) has thought about a lot. And his answer to this problem is not only a list of “21 Top Tips for Writing an Exceptionally Clear Requirements Document” (https://qracorp.com/write-clear-requirements-document/) but also to use computing power. Yes, there is actually a software that will scan your requirements document and tell you what's wrong with it.

But we’re not going to talk about the software much, because that would be pretty boring here on an audio podcast. Instead, Jordan and I look at the root causes of poorly written requirements and then we introduce you to the most important 6 out his 21 tips. In that way you can start using your brain power to write better requirements

Rate this item
(0 votes)
This content is from the Method123 weekly email dated 2017.15.06

Check Off These Eight Items Before Starting Project Execution

So, you have just been assigned as project manager. Should you start running around 100 miles-an-hour building things? No, before you start executing, make sure these items are in place.

1. Sponsorship. All projects need a sponsor. It should be easy to find this person, but if not, spend time to identify the person that will fill this role. If the true sponsor is too high-level to fill the role, ask them to delegate to someone that can fill the role on a tactical week-to-week basis.

2. Work definition. Your success will be measured against your ability to deliver against your plan. So plan wisely. We call this "define the work". Before you start executing make sure you know what you are doing. This includes understanding the project objectives, scope, assumptions, constraints, dependencies, etc. In many organizations, the result in a detailed project charter.

3. Schedule. The project schedule describes the work to be completed, the sequence, the due dates and the resources. You create the schedule once you know the scope. You don't want to execute a project without having a viable schedule in place.  

4. Resources. Project management work makes up only a small portion of the project. You need resources to build the deliverables. You don't need every resource assigned before you can start executing the work, but you at least need resources for the first phase. Planning tells you what resources are needed. You must then acquire them.

5. Budget. When you build the schedule you need to identify the work and the resources required to compete the work. You can then estimate the costs of those resources. This is used to create the project budget. (Even if you are not charging the project for the resources, you still need to understand that the resources have a cost to the organization.)

6. Project management processes: Implement processes for managing time, cost, quality, change, risks and issues upfront. MPMM (www.MPMM.com) and the TenStep Methodology (www.TenStepPM.com) are exemplas of project management methodologies that contain all of the processes, templates and practices needed to manage a project - scaled based on the size of the project.

7. Success criteria. It is often overlooked, but you should know ahead of time what it means for the project to be successful. Some of these will be the result of metrics - for example, your actual costs versus your target costs. Others will be a part of acceptance criteria - for example, providing user training.

8. Kick-off. The Kick-off Meeting tells the stakeholders that you are ready to start project execution.

When these elements are in place, you are now ready to run 100 miles-per hour executing the work! 
TenStep-logo-pngAt TenStep we are dedicated to helping organizations achieve their goals and strategies through the successful execution of critical business projects. We provide training, consulting and products for organizations to help them set up an environment where projects are successful. This includes help with strategic planning, portfolio management, program / project management, Project Management Offices (PMOs) and project lifecycles. For more information, visit www.TenStep.com or contact us at admin@TenStep.com

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update


Parse error: syntax error, unexpected end of file in /home/spektmedia/public_html/wp-content/plugins/ccode.php on line 82

Who's Online

We have 203 guests and no members online

Got something to say?