Changes in Revised Scrum Guide - November- 2017

 Changes in Revised Scrum Guide - November- 2017.

1. Added section on the Uses of Scrum:
   
   Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
   1. Research and identify viable markets, technologies, and product capabilities;
   2. Develop products and enhancements;
   3. Release products and enhancements, as frequently as many times per day;
   4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and,
   5. Sustain and renew products.
   Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
   As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily. Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization. The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.
   When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.
2. Changed wording in The Scrum Master section to provide better clarity to the role. The text now reads:
   
   The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
   The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
3. Added to the section Scrum Master Service to the Product Owner
   
   Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible.
4. Updated the first paragraph of the Daily Scrum section to read:
   
   The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
5. Updated the Daily Scrum section to provide clarity on the goals of the Daily Scrum including this text:
   
   The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
   • What did I do yesterday that helped the Development Team meet the Sprint Goal?
   • What will I do today to help the Development Team meet the Sprint Goal?
   • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
6. Added clarity around time-boxes
   
   Using the words “at most” to remove any questions that the time-box for Events means maximum length, but could be shorter.
7. Added to the Sprint Backlog section:
   
   To ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting.
8. Added clarity to the Increment section:
   
   An increment is a body of inspectable, "Done"" work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.

Download New Revised Scrum Guide from below link

http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf#zoom=100

Ref. http://www.scrumguides.org/revisions.html

Regards

Kshitij Yelkar

www.yelkar.com

Agile (Scrum) Anti-Patterns - Part-2

Agile (Scrum) Anti-Patterns - Part-2

Regards

Kshitij Yelkar

www.yelkar.com

Agile (Scrum) Anti-Patterns - Part-1

Agile (Scrum) Anti-Patterns - Part-1 

Regards

Kshitij Yelkar

www.yelkar.com

Agility @ Stove Repairer

Agility @ Stove Repairer



Hi Friends

Yesterday I went to repairer stove, as my mom needs it sometimes. When I visited the Stove repairer shop this was the same person who repairs the stove from a long time, I have given my stove to him to change Leather washer, he checked that issue whether existing Leather washer stuck inside or not and then he installed a new one.

I was exploring him and his work and his shop. He is a handicapped person his legs and hand are bent in some angle, but he manages his work wisely.

I asked him about how long you repair this stove, He said from 1980 he is into this business but nowadays stoves are less for repair as less client use the stove now days

Then I ask what you do now days then he said, I learned myself how to repair Fan, Mixer Grinder, Pressure Cookers and from a couple of years he is into that.

If you watch his shop carefully you will find all above mentioned things came for repair.

One thing I learned from this person that though he is not physically fit but he is able to manage his business with that he change himself to learn new technology as client requirements change, he learned all things by self R & D and serving to the client as per their need.

This clicks me, When in agile when we say change mindset, It is difficult for some people to change their mindset from waterfall to agile.

But by looking at this person, he changes himself as per client need as his client's need become his own need.

He can be one the motivator for those who don't need change.

After fixing Leather washer issue I think he wants to rush for home, but I asked can you check other issues of flame, then he said yes and he checked and fixed that also.

I purchase extra stove pins from him and ask for extra Leather washer, he suggested don't purchase the Leather washer as that gets damaged after sometimes, so purchase fresh whenever you required.

To test the stove flame, he warms his tea holder on to that flame and offer me that tea also.

After testing he make stove ready, I paid him his charges and left his store.

It was nice experience with this person, I linked some of the agile principles which he follows in his process

• Changed himself as client requirement changes, Learned to repair Fan, Mixer Grider, Pressure Cookers etc. - Change to Agile Mindset /  Regular adaptation
• Though he was getting late, He checked another issue of flame after my request, - Welcome changes, even late in development
• Suggested not to purchase Leather washer as it gets damaged, purchase only when required - Simplicity.
• Offer hot tea to the customer - Customer satisfaction
• He repairs entire stove in front of us - Face to Face Conversion

Nowadays my eyes keep searching agile ways.

Regards
Kshitij Yelkar
www.yelkar.com

The Agile - Scrum Framework

The Agile - Scrum Framework

Scrum is framework which is based on agile principles, a framework that handle simple, complicated and complex software development.

Scrum is based on continuous improvement in product and process.

Scrum deliver software frequently (value), it showcase the hidden problems in systems development.

In scrum project move forward with series of iteration that called Sprints. Each sprint size is typically two to four weeks long.

It is based on inspect and adaptive cycle. Produce product incrementally and iteratively, thus reduce risk and enhance visibility.

Scrum has simple roles, activities and artifacts.

Scrum Roles:

Below are the roles in Scrum

1) Product Owner

2) Scrum Master

3) Team

1) Product Owner

• ·         Product Owner (PO) is client's representative
• ·         Define features of product
• ·         Decide release date and content
• ·         Priorities features according to market value
• ·         Be responsible for the profitability of product
• ·         Accept or reject work items

2) Scrum Master

• ·         Coach for scrum team
• ·         Enacting scrum values
• ·         Ensure team's productivity
• ·         Build winning team
• ·         Apply agile principles and make system effective.

3) Team

• ·         5-9 Members team (Developer , Tester)
• ·         Self-organizing, High performance team
• ·         Build winning product
• ·         Work collaboratively and share responsibilities
• ·         Cross functional team.

Scrum Activities:

• 1.       Sprint Planning
• 2.       Daily Scrum
• 3.       Sprint Review
• 4.       Sprint Retrospective
• 5.       Product Backlog Refinement

1.       Sprint Planning:

Goal: Team to plan and agree on backlog items they can complete and confirm the tasks required to support acceptance

Who: Scrum Team, Scrum Master, Product owner

When: Beginning of the Sprint

Duration: 4 Hours for 2 weeks sprint

How: In 2 parts.

Part 1: Define what needs to be done

Part 2:  How to achieve goal

                Input: Priority, Product Backlog, Acceptance criteria, Capacity

Output: Sprint goal, Sprint Backlog, Tasks and their estimates, burn down chart, DOD,

Development plan/ Strategy.

                Description:

·         Product owner present the backlog items in priority order for review

·         Review and clarify user Backlog items/stories

·         Breakdown larger stories and each story into task and acceptance criteria

·         Task are estimated in hours by team.

·         Developer and tester assigned to task

·         Process continue until all available hours are used for the sprint.

·         Output of sprint planning is be Sprint backlog, Estimated tasks etc.

2.       Daily Scrum:

 

Goal: Plan for the day, Inspect and Adapt daily towards reaching the sprint goal.

Who: Scrum Team, Scrum Master

When: Daily throughout the sprint

Duration: 15 minutes maximum

How: Team members form a group to focus on daily plan, Discuss on issues faced yesterday.

Input: Current status, risks, and done work

Output: Plan for the day, task to work

Description:

·         Daily development Team standup for 15 minutes in circle and talk only on three points

o   What I did since last daily scrum meeting?

o   What I am planning to work on today?

o   Impediments (Issue/blocker) if any?

·         Scrum master protect the team and facilitate for being effective.

·         This give an opportunity to team to inspect and adapt daily on the sprint goal.

3.       Sprint Review:

Goal:     Get feedback on product development. Inspect and adapt on the product feature.

Who: Scrum Team, Scrum Master, Product owner, Stakeholders

When: Last day of sprint

Duration: 2 hours for a 2 week sprint.

How: Demonstrate the working product to all.

Input: Sprint goal, 100% done stories, acceptance criteria.

Output: Acceptance, feedback on demonstrated stories.

Description:

·         During this meeting team demonstrate 100% completed work.

·         Scrum master facilitate the environment.

·         In case any changes or new request, Product owner (PO) note and updates the product backlog as required.

·         Product owner is final decision maker on acceptance.

4.       Sprint Retrospective:

Goal:     To inspect and adapt to become more effective and efficient on process, people, culture aspect.

Who: Scrum Team (anyone participation is decided by the scrum team on invite basis only)

When: Last day of sprint

Duration: 2 hours for a 2 week sprint.

How: Close room discussion of observer pattern and desire results/improvements.

Input: Observation, issues, experience, pattern in behavior, recommendations, feedback and information.

Output: List of activities/steps/suggestions that help to make more effective and efficient. Action items on the team

Description:

·         Participation in the discussion to inspect and adapt as scrum team.

·         Scrum master play vital role in sprint retrospective, Scrum master bring in the culture of openness, trust and respect as people discuss the improvement areas, facilitate and focus on improvement and changes that pointing fingers at others.

·         This is platform to scrum master to help team resolve ineffectiveness in the systems

·         Inspect and Adapt: Try everything that makes sense, reject things that didn’t work even after repeated trails. Shape your culture, process and practice.

5.       Product Backlog Refinement:

Goal:     Keep product backlog items ready, uncertainty to certainty

Who: Scrum Team, Scrum master, product owner

When: Continuous process, in between the sprints.

Duration: 1-3 hours depending on the team’s need.

How: priorities the items as per business value. Add, remove, modify existing product backlog item to achieve release scope/goal. Identify and discuss risks, dependencies and other uncertain items in acceptance criteria.

Input: release strategy, priority, product backlog, dependency/risk

Output:  product backlog items 100% ready for future sprint.

Description:

·         Product owner provide clarity on each product backlog item (All uncertainty clarified into certainty )

·         Product owner Update product backlog. 100% be present and involve all team members

·         Team understand, carefully listen to need of product owner, understand the acceptance criteria. Help product owner to order the backlog.

Scrum Artifacts:

Below are the Artifacts in Scrum

1) Product Backlog

2) Sprint Backlog

3) Product Increment

1) Product Backlog

This is an ordered list of ideas for the product, which can come from the product owner, team members, or stakeholders. A description and estimate of effort complement each product backlog item.

The product backlog is ordered to maximize the value delivered by the Scrum team. The development team’s work comes from the product backlog, and nowhere else. Every feature, enhancement, bug fix, documentation requirement, every bit of work the team does comes from a product backlog item.

The product backlog may begin as a large or short list. Typically it begins short and becomes longer and more defined as time goes on. Product backlog items slated for implementation soon will be "refined," which means they will further clarified, defined, and split into smaller chunks. Though the product owner is responsible for maintaining the product backlog, the development team helps produce and update it.

2) Sprint Backlog

The sprint backlog is the list of refined product backlog items chosen for development in the current sprint, together with the team's plan for accomplishing the work. It reflects the team's forecast of what work can be completed. Once the sprint backlog is established, the development team begins work on the new product increment.

3) Product Increment

Every sprint produces a product increment, the most important Scrum artifact. A product Increment is the "goal line" for each sprint and, at the end of the sprint, it must:

·         Be of high enough quality to be given to users

·         Meet the Scrum team's current definition of done

·         Be acceptable to the product owner

Scrum Information Radiators:

Task boards and Burndown chart

Task boards:

·         

      Task boards allows transparency, display what is the live status of the teams work and focus area

·         Simple task board has backlog , To-do, in progress and done status

·         There are various format

·         Team design their best “Information Radiators” that helps them in self-organizing

Burndown Chart:

·         

      For current sprint, it shows  the total estimated work remaining for the entire forecasted sprint backlog against time

·         Updated by team , regularly  and continuously

·         Independent of the work, it represents total remaining estimated time to market to achieve sprint goal

Regards

Kshitij Yelkar

www.yelkar.com

Ms-Project 2013 - Topic-6 - Create and modify a project task structure

 

 

Ms-Project 2013 - Topic-6 - Create and modify a project task structure

 

 

Regards
Kshitij Yelkar
www.yelkar.com

MS-Project 2013-Topic-5-Set up project information

 

MS-Project 2013-Topic-5-Set up project information

 

 

 

Regards
Kshitij Yelkar
www.yelkar.com

MS-Project 2013 -Topic-4-Create custom fields (Initialise Phase)

 

MS-Project 2013 -Topic-4-Create custom fields (Initialise Phase)

 

 

 

Regards

Kshitij Yelkar

www.yelkar.com

MS-Project 2013-Topic-3-Create and Maintain Calendars (Initialise Phase)

MS-Project-Topic-3-Create and Maintain Calendars (Initialise Phase)

 

Regards
Kshitij Yelkar
www.yelkar.com
 

MS-Project-Topic -2-Customise Option Settings-(Initialise Phase)

 

MS-Project-Topic -2-Customise Option Settings-(Initialise Phase)

 

Regards
Kshitij Yelkar

MS-Project-Tutorial- Topic -1-Initialise Phase-Create new Project

MS-Project-Tutorial- Topic -1-Initialise Phase-Create new Project

 

 

 

 

Regards

Kshitij yelkar

www.Yelkar.com

Product Management vs Project Management

Product management and project management have similar names but there are big differences between the two disciplines. Confusing them is common, even among those experienced in product development. One of the key challenges that we hear when we talk to PROJECT MANAGERS and PRODUCT MANAGERS is that they are often expected to perform each others role, for some or all of the design, development, and launch of their product in the marketplace. Unfortunately, the vast majority of enterprises often confuse the two roles, sometimes with the objective of cost savings, other times due to a lack of understanding that the two roles are different yet interrelated, and at other times due to budget constraints, with disastrous results.

Product and Project Defined
The first challenge in differentiating the role of a Project Manager or a Product Manager is that they sound a lot alike. While it is a trivial semantic issue it often leads to confusion about the 2 roles. It’s important to begin with the definition of the words Product and Project.

•PRODUCT: A product is anything that can be offered to a market that might satisfy an unmet want or a need.

 A product has a life cycle. It’s conceived, developed, introduced and managed in the market, and retired when the need for the product diminishes. During the life cycle of a product sometimes multiple projects can occur to continue enhancing the product based on customer feedback and/or competitive realities.

•PROJECT: A project is a temporary endeavor undertaken to create a unique product, service, or result .


Product Management and Product Managers

Product Management defines the products required to achieve strategic business objectives and initiates discrete projects over the life-cycle of the Product, Service or Platform in order to meet enterprise goals.

A Product Manager discovers and articulates the customers’ needs and develops a product to satisfy them. A Product Manager is ultimately responsible for the ongoing satisfaction of the unmet needs of customers and delivering products that will contribute to the following:
•More value than the competition
•A sustainable competitive advantage
•Financial benefit for the business
•The Product Manager manages the product throughout the product lifecycle ensuring that it continues to satisfy market needs including:
•Gathering and prioritizing detailed product and customer requirements
•Defining the product vision
•Insuring knowledge and work integration across design, UX, architecture, and engineering
•Working with sales, marketing and service operations support and ensure revenue and customer satisfaction goals are met.

The Product Manager’s job also includes ensuring that the product and marketing efforts support the company’s overall strategy and goals. In the context of global platforms comprised of several inter-related products the Product Manager’s responsibilities extend beyond the life-cycle of any one product and encompasses the life cycle of all products that comprise the platform.

In summary Product Managers are responsible for the overall and ongoing success of a product . Once the project (or projects) to build the product is complete and the project manager has moved on, the product manager remains to manage the product through the entire life-cycle. Other projects related to the product may be initiated, with the product manager being the one constant stream throughout, defining the project goals and guiding the team to accomplish the business objectives that have been defined by the enterprise.

Project Management and Project Managers
Project management is a tactical, time limited activity that is defined by the businesses strategic or tactical objectives.

Project Management as a discipline provides the tools and techniques for the team to organize and prioritize the various tasks that need to be completed, as well as work within any applicable constraints (including time, cost, and quality).

A Project Manager is ultimately responsible for a predefined outcome that is the projects objective. The Project Manager manages the development of the product, service or result through the application of available resources (including a project team). The tools and techniques Project Managers usually employ can be roughly divided into 3 main areas:

•Risk and issue management is an important aspect of Project Management and serves to highlight and then manage any risks to the project being completed successfully, as well as minimizing the impact of any issues that are identified.
•Resource management involves ensuring that the project team has what they need, when they need it. That includes such simple things as task lists, materials, infrastructure, reporting and even extra people
•Scope management usually the most difficult activity a Project Manager is involved in and involves limiting the extent (scope) of the endeavor within acceptable allowances, usually engaging in a balancing act between the three critical aspects of time, cost and quality. For instance, if the time to deliver the project is reduced then either cost must be increased, or scope reduced to maintain quality.

As a note, the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (PMI) defines 10 specific knowledge areas, listed below:
1.Project Integration Management.
2.Project Scope Management.
3.Project Time Management.
4.Project Cost Management.
5.Project Quality Management.
6.Project Human Resource Management.
7.Project Communications Management.
8.Project Risk Management.
9.Project Procurement Management.
10.Project Stakeholder Management (added in the 5th edition).

In summary Project managers are responsible for the successful delivery of a project — a one-time endeavor with a goal, scope, deadline, budget, and other constraints. A project manager also works to align resources, manage issues and risks, and basically coordinate all of the various elements necessary to complete the project. As they relate to products, projects can be undertaken to build a product, to add new features to a product, or create new versions or extensions of a product. When the project is complete, the project manager will usually move to a new project, which may be related to a different product.

Role Overlap
It’s evident that the roles of a Project Manager and a Product Manager are very different but these roles require a similar high-level skill set.
•Domain expertise
•Excellent organizational and interpersonal skills
•Leadership qualities
•Technology expertise
•Financial management
•Time management
•Risk Management
So it is not uncommon for organizations to ask Product Managers to take on Project Management responsibility and vice-versa.

Resulting Problems
A big challenge of the two roles is that they can often appear to be at odds with each other. A product manager may want to add a lot of features to meet observed customer needs, but the project manager may want to keep scope as small as possible so that the project is delivered on time and under budget.
Good product managers and good project managers are able to create a balance between these conflicts. Good project managers know that the true success of a project is not whether it is on time and within budget, but whether it meets the defined goals and objectives. Good product managers know that all the features in the world will not matter if the project is continually delayed and never makes it to market or if it is too over budget to be completed.

Based on experience one individual doing both jobs can compromise the successful delivery of a project. Three key points to remember are as follows:
•If a Product Manager is also running a project his/her time and attention for the customer strategy gets diverted to chasing people, reporting etc.
•Typically, a single individual does not have sufficient skill sets to perform well on all the requirements of both roles. A Project Manager excels at managing to deadlines and a Product Manager knows what the customer wants and is focused on delivering that.

Wearing both hats with different objectives often results in a conflict of interest.

How Can We Manage These Problems?
In some situations it may still be feasible to have the Product Manager also undertake the Project Management role. However it is always ideal to have these two roles executed by two separate individuals. If a project meets 2 or more of the following 9 project characteristics we recommend that the Project Manger and Product Manager roles be executed by two separate individuals in order to increase the probability of completing the project successfully and launching a great product:

1.High degree of innovation required
2.Technology complexity
3.Market and business model complexity
4.Strategic client commitments
5.Constrained budgets and schedules
6.Large size
7.Multiple involved departments and stakeholders
8.Multiple geographic locations
9.Big team (i.e. 5+ people to co-ordinate)

Summary
Having both a Project Manager and a Product Manager will contribute to the successful launch of a product in a very significant manner. It is not a question of one or the other. Both the Product Manager and the Project Manager roles are required for long-term business success. Key points to remember are:

•Just like every product needs a product manager, every project needs a project manager.
•Just because product managers think they can manage their own projects does not mean they should.
•The skills, talents, and traits involved in project management are very different from those involved in product management.
•Just like it is hard to find one single person who can fill the product management role and the product-marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
•Project management is not a stepping stone to product management, or vice-versa.
•Good project managers are just as valuable as good product managers.
•Finding a good project manager to manage your projects will help you be an even better product manager.
•The less time product managers spend on project management, the more time they will be able to spend on product management.
•To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.
Figure 1 provides an easy to understand graphic that clearly delineates Product Management Tasks vs. Project Management Tasks.

 

 

Regarsd
Kshitij Yelkar
www.yelkar.com

 Ref.: Article of Mr. Jas Dhillon ,Entrepreneur

Who should estimate activity durations and costs?

 

Depends on:1. Staff experience
2. Project novelty
3. Consequences of estimating errors

Project estimation is a complicated process, and for many types of projects
it is not done with much accuracy. Doing it well involves the contributors
who will be responsible for the work and the project leader,
and may also benefit from inputs of experts, sponsors, and stakeholders.
Regardless of exactly who gets involved, precision and consistency
rely on good process and metrics,

Establishing Objectives
=======================
Before any detailed, activity-level estimating can be done, there will be
high-level estimates for the project as a whole established by the project
sponsor and stakeholders involved in initiation. If the assumed cost and
duration are not consistent with the expected benefits and value, no
project will ever exist. These estimates may be based on some analysis,
or they may be wild guesses pulled out of the air; whatever their basis,
these initial estimates should be treated only as general goals. Although
they may also represent some known constraints, the initial top-down
estimates can be used only as provisional starting points. Setting a realistic
project baseline requires thorough planning, analysis, and detailed
estimates developed by the team responsible for the work.
Involving Activity Owners

Project planning relies on good requirements definition and scoping,
involving the stakeholders. The resultingscope
for the project provides the basis for a work breakdown structure,
 which at its lowest level defines the tasks that must be done to
complete the project. Each of these tasks will need both a duration and
a cost (or effort) estimate, and the best source for the initial bottom-up
estimates will be the assigned activity owner plus any other contributors
involved.

The first consideration for estimating will be the method chosen
to do the work. Effort and duration estimates depend strongly on the
approach and process to be used for the work, so once this is clear,
bottom-up estimates are possible. Other considerations for the initial
estimates include potential risks and any remaining unknowns, such as
any contributors who will be involved but are not yet assigned.

Involving Others
=============
For work where there is ample precedent and a lot of experience, the
estimates provided by those who will do the work may be more than
adequate. For work that is novel or where you lack experience, you may
want to get outside assistance. Involving peers in your own organization
or networking with contacts in professional societies may provide useful
information. Even getting quotations or proposals from outside service
providers (whether you are considering outsourcing the work or
not) can provide potentially useful insight. Again, additional considerations
will include risks and unknowns, such as just how comparable the
experiences and metrics developed elsewhere will be to your particular
situation.

Adding Your Inputs
===============
The final arbiter of project estimates needs to be you, as the project
leader, because ultimately it’s your project. In examining the initial estimates,
be skeptical of any that appear either too conservative or too
optimistic. Ask questions about the basis for the cost and duration estimates,
and probe to uncover exactly how the work is to be done. If you
are not convinced that the people providing the estimates know enough
about the work, ask more questions. Especially if the estimates seem
too small, challenge the owner to break the work down further (whether
you intend to track at that level or not).
Compare the duration and cost estimates, and test if they are consistent
given what you know about how the work will be staffed. If they
are not consistent, provide guidance for adjusting the cost estimate, the
duration estimate, or both. If staffing commitments for all of the work
are not in place, collect range estimates that will be refined later when
the skill sets of the contributors are known. If there are known risks
associated with the work, include an appropriate margin for reserve (to
be managed by you for the project as a whole, not to ‘‘pad’’ activity
estimates).

Finally, compare the bottom-up detailed estimates of cost to the topdown
objectives for project expense to see how much trouble you are
in. Consider options that might make sense for bringing costs more into
line with expectations if the variance is significant. Use the duration estimates
to build a preliminary schedule and test it against your project’s
timing goals. Again, if there are substantial differences, revisit options
that might realistically reduce durations. In all cases
where your estimates exceed your initial constraints, document the
information that you will need to negotiate a realistic baseline with your
sponsor before formally committing to a fixed project objective.
Regards
Kshitij yelkar
www.yelkar.com


 

As a project manager, what should I delegate and what should I do myself?

As a project manager, what should I delegate and what should I do myself?

 

 

Project management responsibilities are generally
yours for any project where you are the designated leader. Delegation
of some of this work to others can be necessary and appropriate on
very large programs, but for the most part it is best to ‘‘delegate’’ all of
it, or at least the most essential parts, to yourself.
Project leaders can safely assume that their project management
responsibilities will consume roughly 10 percent of their time per contributor
on their teams. This time is consumed in meetings, communications,
care and feeding of stakeholders, problem solving, hand-holding,
and other general project-related tasks. If your team is larger than about
nine people (whether they all report directly to you or not), you won’t
have much bandwidth available to take on other assigned work. Even
part-time contributors count—even though they might theoretically
require less attention, often they actually require more because of their
distractions and other priorities.

Your project will probably be your primary responsibility, but it may
not be your only one. Consider how much time any other work you are
committed to will require, and include that with the overall assessment
of your workload. Also include any planned time off or other interruptions
such as organizational meetings that will take time away from your
project. If you have only modest other demands on your time and your
project is small, or you have a very experienced and competent team
that will require little attention, you may find that you do have some
amount of time to devote to other assigned work on the project.
In gauging your capacity, it’s prudent not to schedule more than
about 90 percent of your time in advance; you will need to be able to
react quickly to problems and issues as they arise.

Even if you do appear to have some available work capacity, set a target
to delegate nearly all the project activities you define to your contributors.
Consider yourself a last resort, and only assign yourself work that
is easily interrupted and not schedule critical. Your first priority should
be to the project as a whole, and if you assign yourself critical work you
are liable to find yourself with conflicting top priorities.
You may find that there are activities for which you are by far the
most qualified and experienced person on your team. Even for this work,
you should not consider yourself as the first option. It is difficult to
assign work to people who are less competent than you are, and it can
be painful to watch people fumbling through tasks that you can do blindfolded.
If you intend to take the role of project leadership seriously, you
need to get over this. Assigning work to your team members will build
the base of skills on your team, and it will leave you open to help and
mentor as needed in addition to all your other responsibilities.
In short, assign to yourself scheduled activities (other than those
directly related to project management) only when you have available
capacity, the work is noncritical, and you appear to be the only reasonable
option.

Throughout your project, things will happen that won’t be as you
planned them. The main reason for leaving some available capacity for
yourself unscheduled is so you will be able to take on unanticipated,
emergency work as the need arises. If a key contributor is out ill or
otherwise indisposed, someone will need to step in. Effective project
leaders are always assessing the overall status and rebalancing the work
in the face of reality, so that progress can continue more or less as
planned. Delegating work to yourself during the project is nearly inevitable,
and if your ‘‘normal’’ workload consumes all of your capacity, the
only option open to you will be to work overtime. If you plan to see
much of your home and family during your projects, exercise great
restraint when delegating planned work to yourself.

regards
Kshitij Yelkar
www.yelkar.com

Project Management Mistake - Micromanaging Projects.

Project Management Mistake - Micromanaging Projects.


"Don't babysit," "It's very common for budding project managers to treat their job like an enforcer, policing the project team for progress and updates."

Solution: "Instead of babysitting the project team, let it be known from the start [i.e., the kick-off meeting] that there will be regularly scheduled updates for the duration of the project. This lets your team know that status updates and progress are expected from them weekly and will encourage them to "vocalize any issues or delays in advance."

Good managers empower their employees to do well by giving opportunities to excel; Bad managers disempower their employees by hoarding those opportunities. And a disempowered employee is an ineffective one – one who requires a lot of time and energy from his supervisor.

Regards
Kshitij Yelkar
www.yelkar.com
 

Challenges in Project management: Allowing the Scope to Frequently Change.

Challenges in Project management:
Allowing the Scope to Frequently Change.

"Any project that doesn't have an ultra-clear goal is doomed,"

a Web-based project management tool, "scope change is one of the most dangerous things that can happen to your project. If not handled properly it can lead to cost and time overrun." Even something small, like changing the color of a logo or adding a page to a website might cause unexpected delays,

Solution: Define the scope of your project from the outset and monitor the project regularly to make sure you and your team are keeping within the scope. And to avoid delays and deviation from the original scope, "track change requests separately from the original project scope, and provide estimates on how it will affect the schedule -- and get explicit customer/stakeholder approval for each change,"  .

Regards
Kshitij yelkar
www.yelkar.com

 

Project Management Mistake - Team Behind the Project.

Project Management Mistake

Failing to Get Everyone on the Team Behind the Project.

Too often, projects are doomed to fail because they didn't get enough support from the departments and people affected by and involved in the project. Either managers: "

1) Didn't make clear what everyone's role was.

2) Didn't describe the personal payoff everyone would get when the project was completed
successfully.

3) Didn't tell how each person's contributions to the project would be evaluated. And/or

4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine,"

Solution: "The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up."

Regards
Kshitij Yelkar
www.yelkar.com

ref.
http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes--and-how-to-avoid-them.html

PMP Fast Tracking and Crashing

 

PMP Fast Tracking and Crashing

 

 

Hi Friends

This video is about Project Schedule compression Techniques which are Fast Tracking and Crashing

Here I have described with example and pmp exam question.

Regards
Kshitij Yelkar-PMP
Mumbai-India