Thursday, February 26, 2015

Project Management - Jargons

Jargon's of Project Management

Agile Project Management

The ideas from Agile software development applied to project management. Agile methods promote a process that encourages development iterations, teamwork, stakeholder involvement, objective metrics and effective controls.

Assumptions

Any factors that you are assuming to be in place that will contribute to the successful outcome of the project.

Balanced Scorecard

A performance management tool which began as a concept for measuring whether the smaller-scale operational activities of a company are aligned with its larger-scale objectives in terms of vision and strategy.

Baseline

A baseline is an approved configuration item, for example a project plan that has been signed off for execution. The baseline records the planned costs, schedule and technical requirements against which a project is measured.

BOSCARD

A strategic planning tool used to provide the terms-of-reference for new projects. The BOSCARD acronym stands for Background, Objectives, Scope, Constraints, Assumptions, Risks and Deliverables. These headings are commonly found in terms-of-reference and project initiation documents.

Business Case

A document recording the justification for starting a project. It describes the benefits, costs and impact, plus a calculation of the financial case.

CAPEX

Capital Expenditure (CAPEX) is the amount a company spends to buy fixed assets, or to add to the value of an existing fixed asset with a useful life that extends beyond the taxable year.

CAPM

Certified Associate in Project Management (CAPM) is a certification in project management managed by the Project Management Institute in accordance with their published ANSI standard A Guide to the Project Management Body of Knowledge, shortened to PMBOK Guide.

Change Control

The practice of identifying, documenting, approving and carrying out changes within a project.

Constraints

The factors that you will need to consider during the life of the project that you cannot change. These may include deadlines, regulatory requirements and dependencies on other projects to deliver.

Cost Benefit Analysis

The cost benefit analysis is used to show the expected benefits of a project are sufficient to warrant the cost of carrying it out. Monetary units are usually used for the comparison.

Critical Chain Project Management (CCPM)

A method of planning and managing projects that puts more emphasis on the resources needed to carryout project tasks. It is the Theory of Constraints (TOC) applied to projects.

Critical Path

The critical path is the sequence of activities that must be completed on time for the entire project to be completed on schedule. It is the longest duration path through the work plan. If an activity on the critical path is delayed by one day, the entire project will be delayed by one day unless another activity on the critical path can be finished a day earlier than planned.

Critical Path Method (CPM)

A technique used to predict project duration by analyzing which sequence of activities has the least amount of scheduling flexibility.

Critical Success Factor

A factor identified as essential to achieving a successful project.

Deliverable

A tangible or intangible object produced through project execution. A deliverable can be created from multiple smaller deliverables.

Delphi Technique

A method used to estimate the likelihood and outcome of future events. A group of experts exchange views, and each individually gives estimates and assumptions to a facilitator who reviews the data and issues a report. This process continues until consensus is reached.

Dependencies

Any events or work that are either dependent on the outcome of the project, or the project will depend on.

Earned Value

An approach where you monitor the project plan, actual work and work-completed value to see if a project is on track. Earned Value shows how much of the budget and time should have been spent, for work done.

Estimating

Estimating uses a number of tools and techniques to produce estimates. An estimate is an approximation of a projects timescale and cost that is refined throughout the project.

Float

The time a task can be delayed without delaying the project. Tasks on the critical path have no float.

Gantt Chart

A Gantt chart is a popular project management bar chart that tracks tasks across time. When first developed in 1917, the Gantt chart did not show the relationships between tasks. This has become common in current use, as both time and inter-dependencies between tasks are tracked.

Logic Network

A diagram showing the sequence of activities in a project across time. It shows which activity logically precedes or follows another activity. It can be used to identify the milestones and critical path of a project.

Milestone

A key event during the life of a project, usually completing project deliverables or other noteworthy achievement.

Monte Carlo Simulation

The Monte Carlo Simulation is a technique used to estimate the likely range of outcomes from a complex process by simulating the process under randomly selected conditions a large number of times.

MoSCoW

A prioritization method is used to decide which project requirements must be implemented first and which come later or will not be implemented at all. MoSCoW stands for Must, Should, Could, Would. The o's are added to make the acronym pronounceable

Murphy's Law

The law that says; "If anything can go wrong, it will" named after Capt. Edward A Murphy, an engineer working on US Air Force Project MX981 in 1949.

NPV

Net Present Value (NPV) is an estimate that helps organizations determine the financial benefits of long-term projects. NPV compares the value of a pound today to the value of that same pound in the future, taking inflation and returns into account.

P3M3

P3M3, also known as the Portfolio, Programme and Project Management Maturity Model is a reference guide for structured best practice. It breaks down the broad disciplines of portfolio, programme and project management into a hierarchy of Key Process Areas (KPAs). P3M3 is owned by the Office of Government Commerce (OGC).

Pareto Principle

Named after Italian economist Vilfredo Pareto, the Pareto Principle is the idea that by doing 20% of the work you can produce 80% of the benefit of doing the whole job. Or for quality improvement, most problems are produced by a few key causes.
 

Parkinson's Law

The law that says; "Work expands so as to fill the time available for its completion" by Cyril Northcote Parkinson as the first sentence of a humorous essay published in The Economist in 1955.

PERT Chart

A tool used to schedule, organise and co-ordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a method developed by the United States Navy in the 1950s to manage the Polaris submarine missile programme. Also known as a precedence diagram, a network chart and logic diagram.

PEST Analysis

A strategic planning tool used to evaluate the impact Political, Economic, Social, and Technological factors might have on a project. It involves an organization considering the external environment before starting a project.

RACI Chart

A RACI chart is a matrix of all the activities or decision making authorities undertaken in an organisation set against all the people or roles. At each intersection of activity and role it is possible to assign somebody Responsible, Accountable, Consulted or Informed for that activity or decision.

RAID Log

A RAID Log is a simple project management tool, often in the form of a spreadsheet, used to track Risks, Assumptions, Issues and Dependencies.

Resources

Everything needed to complete the project, but in particular people and money.

Risk

There may be potential external events that will have a negative impact on your project if they occur. Risk refers to the combined likelihood the event will occur and the impact on the project if the event does occur. If the combined likelihood of the event happening and impact to the project are both high, you should identify the potential event as a risk and put a plan in place to manage it.

Risk Management

A subset of project management that includes risk identification, risk quantification, risk response development and risk response control used to identify, analyses and respond to project risks.

Scope

The overall definition of what the project should achieve and a specific description of what the result should be. A major ingredient of scope is the quality of the final product.

Scope Creep

The uncontrolled growth of the project scope resulting from constant changes to requirements without consideration to the impact on resources or timescale.

Scrum

An agile methodology for software project management. Scrum was invented in 1993 by Jeff Sutherland, John Scumniotales and Jeff McKenna.

Six Sigma

Six Sigma is a management philosophy developed by Motorola that emphasizes setting extremely high objectives, collecting data, and analysing results to a fine degree as a way to reduce defects in products and services. See Six Sigma Terminology

Sponsor

The person who has authority over the project, provides funding, approves scope changes, provides high-level direction and champions the project within an organization.

Sprint

An iterative unit of time, typically a one, two, or four week period. The term and concept comes from agile project management techniques in the software industry. Sprints allow teams to leverage incremental improvements. When a company decides to work in two-week Sprints, it has the opportunity to reflect, make adjustments, and plan every fourteen days based on events and conditions.

Stakeholder

A stakeholder is anyone, internal or external to an organization that has an interest in a project or will be affected by its deliverable.

Statement of Work (SOW)

The Statement of Work is the bible for the work the project must produce. The SOW is a key governance tool whether it is being used to direct work for a vendor or contractor, or used to direct the work internally, the SOW must contain a description of all the work that is expected.


SWOT Analysis

A strategic planning tool used to evaluate the Strengths, Weaknesses, Opportunities, and Threats to a project. It involves specifying the objective of the project and identifying the internal and external factors that are favourable and unfavourable to achieving that objective.

TCO

Total Cost of Ownership (TCO) is an estimate of all direct and indirect costs associated with an asset or acquisition over its entire life.

Theory of Constraints (TOC)

Theory of Constraints is a management philosophy of continuous improvement achieved by identifying and managing the most important constraint that affects quality and productivity.

Use Case

The specification of tests that are conducted from the end user perspective. Use cases focus on operating software as an end user would during their day-to-day activities.

Waterfall Model

A sequential development process, in which development flows steadily downwards (like a waterfall) through the phases of initiation, analysis, design, build, test and maintenance. To follow the waterfall model, you move from one phase to the next sequentially, with no overlapping or iterative steps.

Work Breakdown Structure (WBS)

An exhaustive, hierarchical tree structure of deliverable and activities that need to be performed to complete a project. A Work Breakdown Structure is a common project management tool and the basis for much project planning.

Wednesday, February 25, 2015

What is the difference between RFQ and RFP?

What is the difference between RFQ and RFP?

 The difference between RFQ (Request For Quotation) and RFP (Request For Proposal) is that the former is used in the procurement process of a product, while the latter is used when trying to buy a service.

An example of an RFQ is that you want to buy 50 PCs. You send a hardware store your RFQ of 50 PCs (based on your specifications), and they will send you something called a "Quote", containing the individual pricing, the specifications (that sometimes are not an exact match to your specifications), and finally the total price of all your products.

For RFP it's a different story. Let' say your company's website is old, and you want to make a newer one. You send an web company an RFP, telling them that you want a new website and explaining what you need from this website (for example, you need a shopping cart, you need the design to be targeted at the professional audience, etc...). The web company will study your RFP and then will send you a Proposal, listing all the work that will be done, estimating the labor and the project management fees for your new website, and giving you the total cost of your project.

Both the RFQ and RFP are non-binding (so you may send an RFQ and not buy anything, you're just asking how much the price is).

Again, the RFQ is to request the price of a product (note that the product can be non-physical, for example, you're buying MS Office), the RFP is to request the cost of a service.

Sunday, February 8, 2015

How Project Managers Can Anticipate, Avoid and Mitigate Problems

How Project Managers Can Anticipate, Avoid and Mitigate Problems

Problem No. 1: Team members not knowing or understanding what their responsibilities are, not owning their part of the project.

How a good PM handles the accountability problem: Good project managers let team members know, up front, who is responsible for what – and clearly lay out expectations. “One way IT PMs do this is by using a RACI chart where each stakeholder is clearly labeled as one of the following: R = responsible for performing the work of the project, A = accountable for the project results, C = consulted about aspects of the project, or I = informed about the project.”

Problem No. 2: Having key personnel pulled off the project, either temporarily or permanently.

How a good PM handles resource-related issues: Exceptional IT managers are masters at balancing supply (resources) and demand (break/fix issues alongside the project) a project management solution. One way they do this, is by using a “project management system that provides resource visibility and forecasting tools, so PMs can [quickly make decisions, re-allocate resources and] ultimately reduce schedule thrash.”

Another way good project managers deal with team members being pulled in multiple directions? By convincing management that removing a vital team member could delay the project (or worse).
Remember you won't win the fight to keep my best developer [or pick your key team member] without facts. So I rework your schedule accordingly and then present the boss with the impact assessment, [explaining] your project will now be two weeks late and over budget by $45,000 due to the loss of subject matter expertise and learning curve [of his replacement].” The result: “This fact-based impact assessment will often be enough to reverse the decision.”

Problem No. 3: Meeting deadlines.

How a good PM deals with (often shifting) deadlines: To avoid missing deadlines, “I assign my team members specific deadlines for their parts of the project – and the dates I give are always much earlier than I actually need. “That way if something needs to be [fixed], there is plenty of time for changes and another review.”

In addition, it helps if you can break the project into manageable chunks, or milestones, with each chunk or milestone “spaced enough to give you time to make changes before final delivery.”

Problem No. 4: Scope creep.

How a good PM deals with scope creep: Changes affecting requirements almost always stop projects in their tracks. A good PM will need to document the change, validate, assess its impacts, find a solution and have the change request approved before executing the solution. A great PM, however, will do proactive risk and quality management throughout; and not just react to changes. During planning, the PM ensures that all critical stakeholders, e.g., sponsor, SMEs, end-users or other persons of influence, are identified and stayed engaged to minimize surprises and keep future variances at minimum to none.”

It is important to sit down with both your management team and engineer team every time a new feature is added to scope. In this discussion a verdict should be reached on if the new feature is vital to the release or if this is a wish list feature that can wait for the next update (chances are it can wait),” he says. “Another potential solution is … to simply come back and say the scope of this project is locked,” he says. “This will be undoubtedly harder to execute …. [But] you need to stand strong and have your points of emphasis and honestly explain why you cannot add to the scope of the project.”



Problem No. 5: Not being aware there is a problem or potential problem.

How a good PM stays on top of potential problems: A successful PM should have standing weekly [or more frequent] status meetings with team members, to check if everything was achieved as per the timeline; what issues, if any, anybody is facing and remove them; and, if required, re-plan certain tasks. Another way project managers can easily spot potential problems, and “avoid unnecessary status meetings, [is] by using collaborative task tracking software, which provides online project management software. Team members whose tasks are updated and on schedule get extra time to get work done, and you can focus your time talking to individuals who are behind schedule, or who aren't reporting their progress.

Problem No. 6: Managing and collaborating with team members in different locations and time zones.

How a good PM successfully manages a decentralized team: Having a mobile collaboration tool “is a game-changer for IT managers. If someone is mobile, for example, they are limited to the technologies available on their mobile devices. For a long time that meant only basic email access and small file attachments could be shared; no real-time collaboration could occur. Find a good collaboration tool.

Problem No. 7: Lack of communication, or hostility, among team members.

How a good PM heads off potential hostilities: A good project manager checks in regularly with team members, either by phone or in person, to see how things are going – and if there are any professional or personal issues that could affect the project, which need to be addressed.

Project management is not just about task management and schedules. You need to be able to relate to each member of the team [and regularly check in with them]. By doing this, you will gain the team’s trust, and their effort in the project will increase.

Saturday, February 7, 2015

Program Manager vs Project Manager

Program Manager vs Project Manager

Project Managers generally manage a (or often multiple) initiatives that have a fixed life-cycle. There is a beginning, and there is an end. Project Managers are expert task masters, and focus on resolving obstacles to ensure a timely, successful, completion of their project.

Program Managers oversee the ongoing processes of an organization. They are focused facilitators that ensure the overall success of the organization typically with a strong focus on process improvement. They often work across teams and organizations to help facilitate the process in which organizations interact with each-other.

Is there any real difference between PROGRAM Management and PROJECT Management? This is a question I hear time after time.

Although there are several unique differences in these two roles, one might say the short answer is ‘it depends’. In smaller sized businesses the distinction between program management and project management is usually based on organizational structure, company goals and the complexity of the business. In larger or more mature organizations, these roles will be much more clearly defined, aligned with the business and the unique characteristics of each will be observed.
Many organizations still struggle to answer the question of why there would be a need for both project management and program management. To the layman, there is a myth that a program manager simply “wears a bigger and wider hat”.

Key Characteristics with Program Management and Project Management

At the high level, and simplest understanding, there are two key characteristic differences that distinguish program management from project management:

Programs encompass a series of progressive projects with an overarching set of objectives based on scope and scale. Projects have specific and more singular objectives and outcomes.

Program management involves more than simply the oversight of a set of projects. It includes application of common standards, processes, governance and annual budgets that oversee the successful execution of all projects.

Even though there may appear to be many similarities between the two roles, being able to tell what sets apart program management from project management helps companies be more productive and deliver better results.

------------------------------------------------
  • Program management is a long-term initiative that top executives implement to improve an organization’s strategic vision, mission, and competitive status in an industry or economic sector
    • Programs are ongoing in nature. Programs usually span a far greater duration than a project
    • Responsible for revenue and costs that are critical and tied to the financial calendar and results. Budget planning, management and control is significantly more complex in the context of a program.
    •  Programs are governance intensive. They typically have a senior level board that provides direction, oversight and control. The Program Manager facilitates the resolving of disagreements and must be able to influence at the executive level.
    • Executive leadership capability that is more difficult to manage because programs are driven by an organizations strategy and are subject to market conditions and changing business goals.
    • Context, people, politics and negotiating- role is more strategic and focused on the big picture – how the projects within the program result in business benefits. Focus is beyond the end date of the individual projects to the transitional and operational elements.
    • Facilitators and coaches who can inspire and guide project managers and their teams to achieve the strategic goals of the programs.
    • Leadership and vision is measured by the implementation and fulfillment of strategy and realization of benefits like growth, productivity or bottom line results – maximizing ROI and value delivery.
 
  • Project management is centralized management by an individual to plan, organize, control and deploy key milestones, deliverables and resources from conception through completion. 
    • Projects run on project time and have a agreed upon end date.
    • Not responsible for quarterly or annual results. Responsible to manage a, typically, straight-forward budget meeting specifications on time and within budget.
    • Projects may have a similar governance structure but tend to be less governance intensive.
    • Uses a formal change management process.
    • Content, scope, schedules, resources – role is more tactical, narrower and deeper, centred on completing tasks, deliverables and outputs of the project and completing on time and on budget.
    • Projects deliver outputs, discrete parcels or “chunks” of change on time, to budget and to specification.
    • Team player who may contribute to deliverables and motivate others through use knowledge, skills, tools and techniques.
A Program Manager is first and foremost a leader with their primary leadership duty being to turn chaos into clarity for the team. Program managers should never micromanage and should leave project management to the project managers. Project managers need clear direction and circumstances. This allows them to be successful fulfilling the immediate tasks, timelines and goals of the project.

Many project managers look up to program managers and aspire to be in their shoes one day although that is not every project manager’s career path. Business today employs a new level of thinking and management approach at the program level. The person who is good as a project manager may not be proficient as a program manager. Program management may not be for everyone.

In summary – the key differentiators

  1. Program Managers manage a portfolio of projects. Project Managers manage projects.
  2. Programs are Ongoing. Projects End
“One of the true tests of leadership is the ability to recognize a problem before it becomes an emergency.”
~ Arnold H. Glasgow, American businessman and humorist

Items Program Managers Must Know

Items Program Managers Must Know

Program management is not just about managing big projects. Putting together a program and keeping the balance between all the component parts takes a different set of skills to those of managing a project.

1. How To Make Decisions

Strategic decision-making is a core skill for the program manager. Your focus is on the overall Program and ensuring that achieves its goals, so you may have to take difficult decisions at a strategic level.

2. How To Manage Pace

Programs are typically longer than projects. You don’t want your team to burn out. Keeping sight of the end goal is the aim with much of program management, but if it is very far away you want to manage the workload so that you deliver a mix of quick wins and more strategic progress towards your objectives.

3. How To Manage Value

Programs deliver business value – and if they don’t, you shouldn’t be doing them. Value management isn’t something that many project managers have to do. At a project level, the focus tends to be on managing scope, and if the scope is right, the value delivers itself. However, at a program level, you need to be sure that overall there is still value to be had from the program’s objectives.

4. How To Manage Resources

Managing resources to cope with the flexible needs of a program over time is a core skill. Use an enterprise project management tool, which can help with planning at a program level too. Program managers also need to ensure the available team members are skilled in the right things at the right time, so you may need to plan and implement a training program too, especially if you are using new tools.

5. How To Cope With Uncertainty

A project may have a defined beginning, middle and an end, but programs rarely do. Instead, you have a vision of what the company will look like when the transition is complete. The program manager’s job is to manage and deal with the uncertainty that comes from not knowing exactly how you will get there. You’ll also have to support other team members dealing with this as they may not have experience of working in a fluid, undefined environment, and that can be uncomfortable.

6. How To Communicate Effectively

On a program with a long duration, communications are even more important than on a project. You have to ensure that messages are consistent across several initiatives and the business as usual work. Keeping on top of all the communication channels can be a constant challenge, so tap into the software tools you have on hand to log and manage all past and future communication ‘moments’.

7. How To Manage Benefits

As well as delivering organizational value, programs also deliver distinct benefits from their projects. These should be planned, tracked and managed so you can keep an eye on the overall benefits being delivered by the program. It’s sometimes difficult to work out how to measure benefits, so work with all the project managers in the team to establish clear ways of benefits tracking for every project.

8. How To Manage Third Party Suppliers

Project managers do this too, but at a project level it is more about straightforward procurement. On a program you are potentially building partnership relationships that will endure – perhaps even past the end of the program. Projects that complete early in the program lifecycle will move into a business as usual phase. While the program continues you will need to ensure that ongoing relationships forged during the project are still managed effectively. Get some help from your procurement team or a contract negotiation partner if you think that would be beneficial.

9. How To Manage Stakeholders

Project managers manage stakeholders as well, but at a program level it is even more important for these relationships to be effective. Program stakeholders tend to be at a more senior level, and perhaps with a more strategic outlook to those individuals participating in projects. If you have moved to program management from a project manager role, you’ll already have a good grounding in how to engage stakeholders and work with them effectively to deliver successfully. Carry these skills with you to program management. If you have come directly to program management, then you are likely to have had some experience in an operational role and this will also have provided you with the opportunity to polish your stakeholder skills.

Thursday, February 5, 2015

How To Write Good Stories

How To Write Good Stories

Start with the Users

As its name suggests, a user story describes how a customer or a user employs the product. You should therefore tell the stories from the user’s perspective. What’s more, user stories are particularly helpful to capture a specific piece of functionality such as searching for a product or making a booking, as the following picture illustrates

Use Personas to Discover the Right Stories

A great way to capture your insights about the users and customers is to use personas. But there is more to it: The persona goals help you discover your stories. Simply ask yourself: What functionality does the product have to provide to meet the goal of the personas?

Write Stories Collaboratively

A user story is not a specification, but an communication and collaboration tool. Stories should never be handed off to the development team. They should rather be part of a conversation: The product owner and the team should discuss the stories, or even better, write them together. This leverages the creativity and the knowledge of the team and usually results in better user stories.

Keep your Stories Simple and Concise

Write your stories so that they are easy to understand. Keep them simple and concise. Avoid confusing and ambiguous terms, and use active voice. Focus on what’s important, and leave out non-essential information. The following template puts the user or customer modelled as a persona into the story and makes its benefit explicit. Use the template when it is helpful, but don’t feel obliged to apply it. Experiment with different ways to write your stories to understand what works best for you and your team.

Start with Epics

Epics are big, coarse-grained user stories. Starting with epics allows you to sketch the product functionality without committing to the details. This is particularly helpful for new products and new features: It allows you to capture the rough scope, and it buys you time to learn more about the users and how to best meet their needs. It also reduces the time and effort required to integrate new insights. If you have lots of detailed stories, then it’s often tricky and time-consuming to relate any feedback to the right stories.

Decompose your Stories until they are Ready

Break your epics into smaller, detailed stories until they are ready: clear, feasible, and testable. Everyone should have a shared understanding of the story’s meaning; the story should not too big, and there has to be an effective way to determine if the story is done.

Add Acceptance Criteria

As you decompose epics into smaller stories, remember to add acceptance criteria. Acceptance criteria complement the story’s narrative: They allow you to describe the conditions that have to be fulfilled so that the story is done. The criteria enrich the story and make it more precise and testable, and they ensures that the story can be demoed or released to the users and the other stakeholders. As a rule of thumb, I like to use three to five criteria for detailed stories.

Use Paper Cards

Paper cards are not only cheap and easy to use. They facilitate collaboration: Every one can take a card and jot down an idea. Cards can also be easily grouped on the table or wall to check for consistency and completeness and to visualise dependencies. Even if your stories are stored electronically, it is worthwhile to use paper cards when you write new stories.

Keep your Stories Visible and Accessible

Stories want to communication information. Don’t hide them on a network drive, the corporate intranet jungle, or a licensed tool. Make them visible instead, for instance, by putting them up on the wall.

Don’t Solely Rely on User Stories

Creating a great user experience (UX) requires more than writing user stories. Also consider the user journeys and interactions, the visual design, and the nonfunctional properties of your product. This results in a holistic description that makes it easier to identify risks and assumptions, and it increases the chances of creating a product with the right user experience









Storytelling and Software Development

Storytelling and Software Development

It appears the power of storytelling has found a happy and relatively new home in the land of software development, within a process called “Agile”. More and more, this increasing trend is causing a shift in how the programs we all use and love (or love to hate) are being created.

For years, software was more commonly developed under what is called the “waterfall” approach. This classically linear and sequential method was called so because work “flows” down a highly structured and set path. Requirements describing what should be built and delivered are assigned to specific teams, creating an environment where you pretty much have one chance to get everything right.

Agile replaces that by having the teams deliver an increment of value, instead of a small piece of functionality. The idea is to build the software in increments, (instead of tackling the whole project at once), starting with this most important parts first. The crucial way this is done are through “user stories”.

You may be asking yourself, “What’s the difference between an increment of value and a piece of functionality?”
 Great question. This is exactly how Agile is different from the “waterfall” approach. While a piece of functionality is basically the result of a requirement, Agile initially uses empirical data by telling “user stories” from the point of view of the customer on what they want or need.

Here is an example of a “user” story :
“As a dog, I want to be able to order food online so I don’t have to rely on people anymore.”
(I didn’t say it was a “human” user story.)

To further expand on this, I’m sure it’s safe to say that a dog will also have a hard time typing, so an additional user story would probably be needed to include this “increment of value” for all the (dog) users.

What you are basically doing here is telling a story as the user or “product owner”, explaining what you want, and why you want it. I like to think of a user story as a very-high level definition of a requirement, with just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

There are definite perks to Agile’s story telling methods. This firstly allows for specification changes as per end-user’s requirements, apelling more customer involvement and satisfaction. When the team can interact directly with the customer, asking questions, getting clarification, discussing ideas, then there is a greater likelihood that what is produced is what the customer wants.

This also promotes more involved and self-managing teams. A “product owner” (a.k.a. customer) puts stories into the backlog, and then controls the development by prioritizing the stories with the most important ones on top. At the beginning of each “iteration” period, within a “scrum planning” meeting, the team determines what they will commit to over the next 10 business days. They write out the tasks that make that story happen, and development begins. Each day there is a “scrum” meeting, where the team and the “scrum master” get together to review the following:
● What did you do since the last scrum meeting?
● What are you planning to do until the next scrum?
● Is anything holding back your progress?

In the daily scrum, the scrum master is a leader, leading the team through the process. While the scrum master can offer advice, he does not tell the team how to go about their daily development activities. It is up to the team to decide the best course of action. That is what is meant by self management: the team manages the “how” rather than a project manager telling them.

This concept of really listening to the customer, embracing their point of view, while empowering your teams to self-manage, prioritize, and solve their own challenges are why more and more businesses are becoming “Agile”. It’s quite amazing how all of this surrounds the power and importance of telling a story.

Sunday, February 1, 2015

Service level Management - MY WAY TO SLA

Service level Management - MY WAY TO SLA

The goal of SLM is to understand the requirements of the customer and organization, factor in the capabilities of the supplier(s) and then deliver quality services that meet those requirements and are subject to constant improvement. The intent of this is to build a better relationship between IT and its customers.

It is important to have a solid SLM process as it will affect the overall IT Service Management (ITSM) initiative. In fact, if your operations environment is not stable, you should start with Change and Configuration Management first as setting SLAs that can cause everyone to lose confidence in the ITSM effort.

To start the journey, IT must designate a Service Level Manager who is empowered to negotiate with the customers and make commitments that are binding on the IT organization. This person must be very knowledgeable about IT and the business and be an excellent communicator with honed negotiation skills.

The Service Level Manager meets with each customer and understands requirements. The manager then crafts a Service Level Requirements (SLR) document that identifies in business terms what the customer needs.

Next, the SLM manager meets with the suppliers who provision the services that the customer is interested in. These suppliers could be internal, external or a mixture thereof. These suppliers need to review each service and craft Service Specification Sheets for each. If the SLR is a customer-facing document, then the spec sheets can be viewed as the technical underpinning documents outlining how the business requirements will be met.

Metrics Must Mean Something to Customers
Now, derived from the customer's requirements set forth in the SLR and the supplier inputs in the spec sheets, the manager crafts a Service Quality Plan (SQP) that puts forth key performance indicator metrics and any critical success factors for monitoring the performance of the service. It is important that the metrics have value to the customer and IT, not just IT.

When communicating with the customer and ensuring requirements are met, it is very important to be measuring what matters. For example, what value does availability as a percent really serve if the business lost a painful $2 million during an outage that occurred during the 0.001% of unplanned downtime?

At this point, the manager needs to negotiate the agreements relating to provisioning. The Service Catalog documenting what IT can provision must be developed or refined if it already exists. The Service Level Agreements (SLAs) stating what IT and the customer will each provide and how the relationship will be managed must be crafted. The Operational Level Agreements (OLAs) stating how IT will meet the service levels that are needed and the Underpinning Contracts (UCs) committing vendors must be set as well.

To be clear, the OLAs are used with internal groups to ensure they can provide service levels that enable IT to meet the customer's defined Service Levels. UCs are used with vendors/third parties to ensure they can meet defined Service Levels.

The creation of these agreements will require repeated sessions of negotiation, creation of drafts, amendments and reaching a final conclusion for each that commits the involved parties. This level of negotiation is why the Service Level Manager must be skilled in both communications and negotiations plus have a solid understanding of the IT organization and the business.

When creating the aforementioned agreements, always think about how objectives and service levels can be crafted such that they are "SMART" meaning they must be specific, measurable, attainable, realistic and timely. One reason for these attributes is that once the agreements are set performance must be measured using the critical success factors and key performance indicators set forth in the SQP.

It's About the Relationship
Lastly, one comment on SLAs - keep them simple. An SLA is not a contract - it is a formal expression of a relationship. If a SLA is so complicated that nobody can understand it and therefore gets confused as to what to do when and how then the results can actually be counterproductive and harm both service levels and the relationship with the customer. IT exists for the customer - not the other way around and some careful give-and-take may be needed.

On an ongoing basis, for example monthly or quarterly, the Service Level Manager should sit down with the various customers to review the performance of IT relative to the services provisioned for each customer.

In areas where corrective action is needed, a Service Improvement Plan (SIP) should be launched and one of the outcomes may be to revise the previously defined service levels. These Service Review meetings are a great opportunity to not only discuss performance but also the direction of the customer and IT. Whenever there is a customer contact point, that opportunity should be used to understand what is going on with the customer and to update the customer about what is going on in IT.

The idea is to build the relationship constantly. If the relationship is lost, then all of the service level documentation is pretty much pointless.

The most important things coming from SLM are not voluminous agreements that sit on a shelf. In other words, the goal is not to simply create documentation. Instead, the true benefits lie in understanding the needs of the customer, measuring IT’s performance against those requirements and then continuously seeking methods to improve the provisioned service levels. In this manner, IT can deliver quality services to the organization that enables organizational goals to be met.

SLA vs OLA



Brief look at SLA vs OLA


Service Level Agreement
•    A Service Level Agreement (or SLA) is an agreement between two or more parties, where one is the customer and the others are service providers.

•    A Service Level Agreement is the service part of a contract which defines exactly what services a service provide will provide and the required level of standard for those services.

•    The SLA is generally part of an outsourcing or managed services agreement, or can be used in facilities management agreements and other agreements for the provision of services.

•    The SLA should set out the overall objectives for the services to be provided, included a detailed description of the services.

Operational Level Agreement
•    An operational level agreement (OLA) is a contract that defines how various group within a company plan to deliver a service or set of services.

•    OLA’s are designed to address and solve the problem of IT by defining the specific set of IT services that each department is responsible for.

•    OLA(s) are not a substitute for an SLA

•    The purpose of the OLA is to help ensure that underpinning activities that are performed by a number of support team components are clearly aligned to provide the intended SLA.

•    OLA(s) have to be seen as the foundation of good practice and common agreement, the sum of which contribute to an SLA

(Service Provider) <<<------Operational Level Agreement (Service Level Targets – Completion or Acceptance) <<----- (Department or OU)
           
SLA vs OLA
•    SLA is what a company as a whole, is promising to the customer
•    OLA is what the functional groups promise to each other in an organization
•    SLA is directly impact to the financial part of an organization
•    SLA has to be measured and completely supported by the OLA’s that the SLA is reliant on
•    OLA will need to state everything that the functional group will need to do in relation to each other to support the SLA