Jargon's of Project Management
Thursday, February 26, 2015
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.
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.
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
- Program Managers manage a portfolio of projects. Project Managers manage projects.
- 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 illustratesUse 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 experienceStorytelling 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
Subscribe to:
Posts (Atom)