Project Management Office (PMO)

PMO definition as per PMP:

A PMO is an organized body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain.

Why you need PMO?

Create Work Breakdown Structure (WBS)

Create WBS (Work Breakdown Structure) is the process of subdividing project deliverables and project work into smaller, more manageable components.

The Create WBS process is part of the Project Scope Management knowledge area in the PMP.

Inter personal skills of Project Manager

The “Interpersonal skills” also known as “Soft Skills” of the project manager make big difference in the project to build the team to improving the competencies, team interaction, and team environment and to achieve the goal of the project.

Inter personal is the important tool in the “Develop Project Team” process in the “Project Human Resource Management” knowledge area as per PMP.

Project Cost Estimation and Control

Project Cost Estimation and Control:

The cost estimation of the project involves estimate costs and control costs.

The below tutorial provides the example of cost estimation, monitoring and forecasting for the project.

The effort estimation, over head costs, software's and hardware's cost are not covered.

Stakeholder Management

A stakeholder is anyone who is affected either positively or negatively by the cost, time, scope, resources, quality, or risks of your project.

Use Case Point Estimation

Use Case Point Estimation:

Use case modeling is a popular and widely used technique for capturing and describing the functional requirements of a software system.

The designers of UML recommend that developers follow a use case driven development process where the use case model is used as input to design, and as a basis for verification, validation and other forms of testing.

A use case model defines the functional scope of the system to be developed. The functional scope subsequently serves as a basis for top-down estimates.

An important prerequisite for applying a use case based estimation method is that the use cases of the system under construction have been identified at a suitable level of detail and the division of the functional requirements into the use case. The use case model may be structured with a varying number of actors and use cases. These numbers will affect the estimates.

Risk Management

Risk is the net negative impact of the exercise of a vulnerability, considering both the probability

and the impact of occurrence.

Risk management is the process of identifying risk, assessing risk, and taking steps to reduce risk to an acceptable level.

Not all the risks are negative. Some events (like finding an easier way to do an activity) or conditions (like lower prices for certain materials) can help your project! When this happens, we call it an opportunity… but it’s still handled just like a risk.

As per PMP the project risk management process are:

Agile Iteration Planning

Agile iteration:

Agile iteration is a consistent time-box in which a delivery team plans, delivers and receives feedback on a product increment.

Conflict management

While no single definition of conflict exists, most definitions seem to involve the following factors:

That there are at least two independent groups, the groups perceive some incompatibility between themselves.

It’s probably no surprise that over half of conflicts come from priorities, schedules, and people. That’s why so many of the processes are focused on preventing conflicts.

Ground rules, good planning practices, and pretty much anything that has to do with communication are all there to prevent the most common reasons that conflicts happen.

Project Kickoff meeting

The kickoff meeting for a new project is your best opportunity to energize the group and establish a common purpose toward completing the work.

To thoroughly understand the role of the kick-off meeting on the success of a project, we must be clear about the purpose(s) of this first project meeting. 

Project Charter

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning (if possible) and preferably while the project charter is being developed.

The project charter officially sanctions the project. Without a charter, the project cannot begin.

Project Statement of Work (SOW)

Project Statement of Work (SOW)

The project statement of work (SOW) is a description of products or services to be delivered by project.

Types of SOW:

Internal Project - The project sponsor or initiator provides the SOW based on the business need.

External Project – The customer provides the SOW as part of bid process.

ITIL Service Portfolio Management

ITIL Service Portfolio Management

What is Service Portfolio?

The Service Portfolio represents a complete list of the services managed by a service provider; some of these services are visible to the customers, while others are not. It contains present contractual commitments, new service development, and ongoing service improvement plans initiated by Continual Service Improvement. It also includes third-party services which are an integral part of service offerings to customers 

Decision Analysis and Resolution (DAR)

Decision Analysis and Resolution (DAR)

The presentation introduces DAR process and example.

RACI Chart

RACI chart is used as tools and techniques in “Develop Human Resource Management Plan” process which is part of Project Human Resource Management knowledge area and Initiating process group.

R.A.C.I = Responsible.Accountable.Consulted.Informed

Problem Management

What is  Problem Management ?

The problem management appears in Service Operation process of ITIL v3.

The objective of ITIL Problem Management is to manage the lifecycle of all Problems. The primary objectives of Problem Management are to prevent Incidents from happening, and to minimize the impact of incidents that cannot be prevented. Proactive Problem Management analyzes Incident Records, and uses data collected by other IT Service Management processes to identify trends or significant Problems.

Daily Agile Scrum stand-up meeting guidelines

Daily Agile Scrum stand-up meeting guidelines:

Followers of the Scrum method of project management will typically start their day with a "stand-up meeting". In short, this is a quick daily meeting (15 minutes or less) where the participants share the answers to the three questions with each other:

What do we talk about during the daily stand-up?
Yesterday Today Obstacles 

Functional Point Analysis

Objectives of Function Point Analysis

Most practitioners of Function Point Analysis (FPA) will probably agree that there are three main objectives within the process of FPA:

1. Measure software by quantifying the functionality requested by and provided to the customer.
2. Measure software development and maintenance independently of technology used for implementation.
3. Measure software development and maintenance consistently across all projects and organizations.

Demand Management

Demand Management:

Demand management is a critical aspect of service management. Poorly managed demand is a source of risk for service providers because of uncertainty in demand. Excess capacity generates cost without creating value that provides a basis for cost recovery.

 

SWOT Analysis

SWOT analysis:

SWOT analysis tool used in “Identify Risk” process of “Project Risk Management” knowledge area and “Planning” process group by PMP.

This tool is required to make sure all the possible risks are identified and included in the “Risk Register”.

SWOT analysis lets you analyze Strengths, Weaknesses, Opportunities, and Threats.

First start by brainstorming strengths and weaknesses, and then validate the strengths to find opportunities, and look at the weaknesses to come up with threats to the project.

What is Agile Scrum?

• What is Scrum?

Scrum is an agile approach to software development. Rather than a full process or methodology, it is a framework. So instead of providing complete, detailed descriptions of how everything is to be done on the project, much is left up to the software development team. This is done because the team will know best how to solve the problem they are presented. This is why, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, and Exit criteria (ETVX) as would be provided in most methodologies.

Team Building

People working together can sustain the enthusiasm and lend support needed to complete the project.

Teams succeed when members have:

·         Commitment to common objectives;

·         Defined roles and responsibilities;

·         Effective decision systems, communication and work procedures;

·         Good personal relationships.

T.E.A.M = Together Everyone Achieves More.

The many faces of a Software Developer

          A software developer is a person concerned with facets of the software development process. Their work includes researching, designing, developing, and testing software. A software developer may take part in design, computer programming, or software project management. 

Ways to Reduce Project Management Distractions

• Relentless Focus – Multi-tasking doesn’t work. Instead, focus on one task and continue with this until completed.
• Block out Chunks of Work – Instead of stopping and starting, work on a specific task (or set of tasks) that are inter-related. Report writing is a good example. Instead of doing reports in fragments throughout the week, schedule an hour and do them in one blast.
• Postpone Email – Instead of checking your email throughout the day, check it AFTER you’ve planned your day. This is very important so I’ll repeat it. Plan your entire day first and THEN check your email.
• Create Templates – If you get the same type of questions rather frequently, create a set of answers and save them in a text file on your desktop. Then cut and paste when needed. Or save them to a folder in your email software and copy/paste from there.

• Setup an Autoresponder – Remind people that you won’t be able to answer all emails immediately. This is to set (i.e. reduce) expectations in others that you’ll respond to every minor question they send over.
• Wear Headphones – People will be more reluctant to interrupt you if you’re wearing headphones as they may assume you’re on a conf call, listening to a webinar, or just need to concentrate.
• Book a Room – Make this recurring. Schedule a room away from your office where you can work in peace. Make this your refuge and go there whenever you need to. Add a Do Not Disturb sign if necessary.
• Learn to Say No – You don’t have to accept every meeting request. Ignore those that do not drive your project forward. Likewise, decline invitations to other time-wasting activities that drain your energy and pull you away from your goals.
• Ignore FYIs – Some folks will send FYIs to cover their own…. Ignore these and do not respond. If possible, setup a filter in your email software and send them all there.
• Create Expectations In Others – When you send out emails to your team, add a tag in the headline. For example, [Status Report] , [Budget] or [Schedule] so they know what’s coming in the email AND when they respond you can identify which email is the most urgent. You can also send them to their respective folders for better organization.
• Deflect Quick Questions – If interrupted by some one who wants to ask a quick question, ask them [immediately] what they want from you. If they ramble on, say you’ve got a call in 2 min. Can they email you the question instead?
• Keep your phone in a drawer – You can’t get work done if your phone keeps looking for your attention. Put it in the drawer and get back to work. Check it at breaks. Most messages will be FYIs and other time-wasters. You don’t have to respond to every text!
• Social Media Diets- if you have to, check it in batches of 10 min. Then leave
• Screen Your Desk – if your co-workers (i.e. sitting across the desk) are distracting you, request a screen to divide the tables. Tell your boss this will improve your productivity and pay for itself within a week. It will. Your co-worker won’t like you but your boss will respect your decision.
• Leave Meetings Early – I rarely attend meetings until the end. Instead, I request that I can share my status report first and then go. Unless it is critical that I stay, the meeting notes and action points should be enough. Over the course of the week, this gives me 7-10 extra hours.
• Work in Full Screen – I’m typing this on a MacBook Pro. When I click the Full Screen mode it blocks out all other applications, including the status bar. No Skype calls flashing for my attention. Find software that helps you stay focussed and reduces distractions. You can also get software that kicks you off the web for 30 min (or whatever period of time) so you have to focus.

Friendly People – If you have a ‘chatty’ type that likes to drop over and chat, use the same technique as above. One twist is to NOT open the conversion with ‘what’s happening’ but ‘what can I do for you?’ This sets the tone. You’re working, busy, time is scarce. Shouldn’t they be working too?

Agile Scrum Questions and Answers

Question: What is a Product or Project Backlog?
Answer: A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Question: Who provides the requirements in Product or Project Backlog?
Answer: It is typically the role of a product owner or a customer to provide the requirements. However, sometimes analysts from the development team can work with product owner or customer to define the requirements. The idea is for the product owner or customer to work with the team to discuss the requirements during the sprint planning meeting.

Question: How are the requirements written?
Answer: There is no standard way to write the requirements. One team can simply write “users sign in” and another could write “users should be able to sign in with their email address and password”.

Question: Is additional information captured in the requirements?
Answer: Yes and no. It depends on project to project and requirement to requirement. Something like Forgot Password might not need further information but something like User Registration might have various notes on each field like date of birth (should be 13 or more) and password (strength).

Question: Do we require “acceptance tests” for the requirements?
Answer: Yes, highly recommended. However, having acceptance tests for all requirements would be too time consuming. Also, the team and product owner or customer should discuss the acceptance tests for each requirement in detail during the sprint planning meeting. It is useful to remember that Agile is collaborative and both the customer or product owner and team should discuss and agree on “definition of done” before the start of a sprint.

Question: Do we need details on everything for each requirement on the backlog?
Answer: This is not really required, although nothing stops you from going this route. However, the closer the requirements are placed to the current sprint, the better they should be defined.

Question: Do we need to estimate each requirement in the backlog?
Answer: Yes, it is recommended that each requirement be estimated. The requirements far from the current sprint can only be coarse grained and hence roughly estimated. However, this gives product owner or customer a rough idea of the project size and number of sprints required to complete a project. The final number of sprints could be more or less, but at each stage the visibility of progress would be self evident.

Question: How is the estimate done - in days or in hours?
Answer: You could use either, although relative estimation would work better. The team and product owner get together at sprint planning meeting. They pick up the simplest requirement from the list and arbitrarily assign a number to the same [say 1 or 1 requirement point or better still 1 coffee cup]. All other requirements are estimated in similar units [requirement points or coffee cups]. At the end you total up the points. At first the team could take a guess at the amount of points it could complete in a sprint. After a few sprints, they would have visibility of how many points they should ideally take. This estimation technique works well to give you rough idea of work that can be picked up. Its not supposed to be used for precise calculations or a point in horizon rather just aim for a region in horizon.

Question: How do we estimate - based on size or complexity?
Answer: The short answer to that is both! Entering 1000 records in database might not be complex, but time consuming and on the other hand investigate SOA performance issues in reports in a clustered environment may be complex and hence, difficult to even give a precise estimate on. And in some cases, you might want to factor in both. Hence, you estimate both from difficulty level as well as effort required.

Question: How is the backlog prioritized?
Answer: It is the responsibility of product owner or customer to prioritize the backlog. The team can provide assistance in the same though. The backlog is prioritized by factoring in risk factor of not doing the requirement right now and opportunity by delaying the requirement decision later. In simpler terms, risk factor, dependencies and business value would help the team decide the priority.

Question: Does the backlog provide any tracking?
Answer: Yes, you can make a simple tracking of completed/ pending items. You can also track number of requirement points completed in a sprint and based on average requirement points completed in a sprint and total requirement points pending, you can get an idea of the projected completion date. The average requirement points completed in a sprint is also called velocity.

Question: Is there a low level tracking involved?
Answer: Yes, you can divide each requirement into tasks. Each task can be estimated in number of hours it would take to complete. This is typically done only for a given sprint and is called a sprint backlog and is maintained separately from product or project backlog.

Question: Is the product or project backlog only made once - at the start of a project?
Answer: No! There are only two rules. First,the product or project backlog should be revised and continuously updated based on emergent scenarios and situation. Second, the backlog for the sprint currently in progress can’t be changed. The backlog for upcoming sprints can be changed almost completely. In a fixed price scenario, this might mean you need to swap new functionality with existing functionality.

Waterfall Model Vs Agile Scrum

Traditional software development methodologies such as Waterfall Model has been quite famous and been used by many software development teams and enterprises across the world. A typical Waterfall Model is as shown below;

·         It follows a very logical path, first do a thorough study on the customer requirements and then freeze the requirements.

·         Frozen Requirement Spec is then analyzed by the design team and a complete design document gets written, documented and reviewed by every stake holders.

·         Design document gets translated in to the product and gets tested/verified by a group of verification engineers/customers etc.

·         Once the product is released in to the market, enters in to maintenance mode.

Though Waterfall Model is logical, there is a biggest flaw in it. Every stage waterfalls in to the remaining and the main threat to the project that follows Waterfall Model is the first stage, that is “Requirements” stage. In real life, requirements never get frozen; for various reasons;

·         Customers do not know exactly what they want; they change their mind often

·         Market is volatile – priorities change overnight

·         Competition from rival companies

·         Humans can not predict a long term product development cycle.

·         Release happens at the end – generally months after customer provides requirements. Often, they don’t get what they wanted. Now, they can not change requirements as it is too late.

These are the major factors make Waterfall Model to fail often since project involves Humans. This is the primary reason why Scrum gained its popularity.

Scrum is based on;

·         Team takes a shorter step in a fixed iterative manner

·         Team along with the Stakeholders/Customers inspects what was developed and adapts changes as needed as per customer requirements. Customer comes to know in a shorter time about the product they are waiting for. They can provide comments etc

·         Scrum encourages changes – team wants customer to have the best possible product that improves/enhances lives of customers. Where as Waterfall Model discourages changes at the later stages.

·         Scrum understands that good ideas can come at any time during the project. Waterfall model does not.