Sunday, April 16, 2017

3 Tips for Effective Planning

Program and Project managers are always at the edge of their seat when it comes to planning. In a common release cycle, while one release cycle is coming to a close, the next one is already in execution phase, while one needs to look into the planning aspects of the forthcoming release.

So,  a program manager is in touch for different releases with the QA, Dev Ops, Development, Product Managers, UI Designers, Architects, Senior management and rest of the stake holders for different reasons depending on the different phases of the release cycle.

It is of utmost importance to be be always be up to date with how processes are working in the organisation for effective scope, delivery and quality management.

Here are quick 3 effective tips to ensure that planning is as effective and producing the desired results.

1. Process: Ensure that the processes are up to date. Find out the process gaps. Communicate across the teams and observe through releases as to what works and what doesn't. What is the gap in terms of meeting deadlines, inter team dependencies, quality and scope management. Apart from observing the deliveries, involve in meetings and get useful pointers in retrospectives, review meetings and take actions to resolve them.

2. Tools: This is the next important aspect. See, how these process gaps can be addressed through effective project management tools. It could mean doing away with tools that are not effective and not scalable, or tweaking the tools to relate to the changed processes, effective or creative ways to track the progress in terms of adding new data points. This always does not mean that you have to fix the tools. But a prudent look at how tools are supporting he team to log and track progress is important and should be looked into from time to time.

3. Planning the plan: This in essence means planning how to plan. Once you are aware of the process gaps, and tool related changes, relook at how can you plan better. Try to understand if there is a need to change in process templates, need to present and track the plan in any different way etc. Once done, a program manager needs to follow the updated plan, process and tools and educate the project managers and the stakeholders as to how it can bring in value to the team.

Saturday, November 28, 2015

Is your Agile project focused on delivering the right value?

You may be focused on your Agile processes, tools and techniques. But, all this may not be delivering the right value to the customer. At the end of the day, it's the customer who has to be benefit from the deliveries made through iterations and Release delivery.

If we re-look at the traditional Iron triangle, the project focuses on the 3 key areas i.e., Schedule, cost and time. However, the moment we talk of Agile, we take it a step further. i.e., the focus is on Value (features), quality and the iron triangle. i.e., to say that the iron triangle itself is considered as one of the points in a triangle. The remaining 2 angles are quality and value. Once this fundamental difference is understood, the priorities are also fixed accordingly.

So, when it comes to focus on the values, we talk of the features. And prioritizing the features is of utmost importance. To ensure that the features or functionalities are focused towards the customer, we use a concept of MMF i.e, (Minimum Marketable Features).
MMF is the smallest set of functionalities that provides maximum value to the project and to the customer. This is based on the Pareto's principle that 80% of benefits comes from 20% of requirements.

So, by focusing on the MMF, maximum value can be delivered in the project at an early phase or initial releases. This helps set off the pressure and also provide more flexibility to the team as the project moves on and the customer gains more confidence about the value that it receives in the project. This has been key to all leading companies across the globe.

To ensure that you get maximum benefit from MMF, the following steps would help:

1) Determine MMF - Ensure that you as a program manager work closely with the product manager to help iddentify the MMF. which would be the most important and high priority features that the customer is expecting.

2) Introduce Slack and manage the change - Ensure that when you plan for the release, include the MMF an the Nice to have features below. This would help to manage the change later, when the customer comes up with new features or functionalities that could not be thought of earlier.
3) Increase MMF - Once the new changes or feature sets are identified, include the new feature at the right priority and remove the slack in terms of the Nice to have features. So, the release inclues the new features as part of the MMF, i.e., the new set of high priority features. As you see in the below illustration, the Release scope now includes MMF with the new feature and excludes the Nice to have Feature 7. Its quite possible that the new feature effort may be equivalent to two nice to have features. In this cae, Feature 6 and Feature 7 both. So, the Release would end up having only the minimum marketable features (MMF).
To ensure that this works efficiently, the features, epics and stories need to be groomed periodically. There needs to be active feedback sessions with the customer between Sprints. The Sprint backlog needs to be re-looked at in every sprint, while the feature sets should be re-prioritized during every release.


Saturday, November 21, 2015

Forecasting the Financial Stability of the Project



The Time value of money for projects is calculated not only in terms of money, but also in terms of:

  •         Return on Investment (RoI)
  •         Customer satisfaction
  •         Employee satisfaction
  •         Innovation Rate
  •         Customer Usage
  •         Customer retention
  •         Repeat Customer
  •         Revenue per employee

The forecasting value helps in determining whether the project is beneficial to proceed or to stop the project (fail fast).
Product owners are primarily responsible for maximizing the project value.

The primary reason for undertaking projects are:

  •         Increasing the revenue
  •         Reducing operating cost by automating work flows
  •         Regulatory compliances
  •         Performance improvement.

Whatever be the reason for running projects, forecasting the financial stability of the project is done using following methods:

  •         Return on Investment (ROI)
  •         Net Present Value (NPV)
  •         Internal Rate of Return (IRR)
  •         Payback period

Return on Investment (ROI): ROI is a performance measure used to evaluate the efficiency of an investment or to compare efficiency of a number of different investments.
ROI – Projected benefits – Costs / Costs
Higher the ROI, better for the project. So out of multiple projects, the order of selecting projects would depend on how high the ROI is.

Net Present Value (NPV): NPV is a method of calculating expected net monetory gain or loss from a project by discounting all expected future cash inflows and outflows to the present value.
In simple terms – It is a measure of the amount of money the project is expected to earn in today’s value.
So, if NPV is positive, accept the project. Out of multiple projects, it is prudent to select a project with higher NPV.

Internal Rate of Return (IRR): IRR shows the interest rate at which NPV becomes zero. IRR is calculated by a company as a minimum threshold to break even.
A project with higher IRR is always preferred. SO, from multiple projects, one should prefer the one with higher IRR.

Payback Period: It is the amount of time taken to regain the net amount invested in a project, i.e., to break even. Companies always prefer shorter payback period.

So as a summary, select a project that has higher NPV, ROI, IRR and a shorter Payback period.

Sunday, November 15, 2015

Agile methodologies: demystified

All Agile methodologies mostly share the same philosophy expressed in the Agile manifesto, but they differ in terms of the practices, processes and techniques.
The Agile Manifesto was signed on Feb 2001 by 17 leading software developers, where the idea is to uncover better ways of developing software through execution and helping or enabling others to do it as well. So, here the program management has a key role to play by facilitating an environment to bring in changes, flexibility and improvement through iterations.
Through this, we have come to value:

Individuals and Interactions over processes and tools.
Working Software over comprehensive documentation.
Customer collaboration over contract negotiations.
Responding to change over following a plan
Though there is value in the item on the right side or written later, but we value the former items i.e., on the left more.
The different Agile methodologies that share this common manifesto across the shared framework are as follows:
Scrum – This is the most popular methodology, which is simple with proven results. This is also the most widely used methodology across industries that have embraced Agile. It focuses mostly on managing the changes to the requirements. A single source of prioritized work items are maintained. The process mostly focuses on working towards a potentially shippable incremental product in each Sprint. The team size varies from 5 to 9. It has 3 key roles of Product Owner, Scrum Master and Team members.

Extreme Programming (XP) – This is primarily used to respond to the high cost of changing requirements. This methodology focuses on Test driven development, Continuous integration, Iterations and user focused stories.
The principles it relies on are Communication, simplicity of requirements, constant feedbacks, and courage to refactor and remove obsolete codes. This is achieved through mutual respect and pair programming approach.
It uses the techniques of Fine – scale feedback, continuously evolving processes, programming at sustainable pace, and shared understanding.
CRYSTAL – This approaches the projecets by categorizing them based on their size, number of people involved and complexity. The project categorization ranges from the least critical projects with less people to large teams handling complex projects. The categories primarily used for categorization are Money, Comfort and Life.

Dynamic Systems Developments Method (DSDM) – is more of an evolution of Rapid Application Development (RAD) to bring in more discipline to RAD concepts that was used earlier. It primarily focuses on the business requirements and needs. Accordingly, it prioritizes requirements through MoSCoW (Must, Should, Could). Accordingly, the schedule, cost, quality and features priorities are set.
Feature Driven Development (FDD) – This methodology mostly focuses on features. The subject areas are then decomposed into business activities. The approach is towards developing a prototype first and then getting into the actual coding and delivery.
Agile Project Management (APM) – The Agile Project Management methodology is built on the Agile manifesto principles with a key difference that the focus is on the Agile value driven triangle instead of the traditional Iron triangle in project management.
The traditional project management focuses on Schedule, Cost and Time, while the Agile project management (APM) focuses on Value and Quality (as the 2 corners of the triangle) by managing the 3rd corner comprising of Schedule, Cost and Time.

Lean Kanban – Kanban, a Japanese term for signal board, was developed where in the boards are located in the team room and have user story cards or post-it notes. Distributed across different categories.
It helps in identifying bottlenecks, work in progress limits etc,.

OpenUP – OpenUP is based on the Open Source variant released by IBM. It’s a lean unified process focusing on the iterative approach embracing Agile philosophy. It targets small projects woth collocated 3 – 6 member teams.

Though the most common approach is Scrum methodology, and the different methodologies are used in different scenarios, a combination of 2 or more methodologies is also used to get the best results using Agile framework.

Saturday, July 4, 2015

5 tips to have a grip on your critical project

Some projects are very critical from the point of view of 
- Customer expectations
- An early adopter going live who would take a decision on whether to invest in your product or services, or 
- Existing customer who could be a major bread earner for your company or having strong political clout.

In such situations the project needs to be more stringently tracked and controlled.  You cannot afford to miss a single milestone. You need to ensure that the required quality is maintained.

But then projects do not operate on ideal situations or controlled environment. There can be situations where in some internal  milestones can get missed without compromising on overall timeline. There can be situations where certain external dependencies can trigger a delay in the delivery of a few modules. There can be risks coming in due to last minute addition to scope that would have been committed to the customers by another group or team that was not part of the original plan. 

Such projects and such situations definitely require one to follow the best project management practices.  But there is this little bit of extra that can help ensure success in such projects. Here are five tips that can help you in such situations. 

1) communication -  yes.  This is the key to managing any project. However,  why I iterate this here is because such critical projects need a little extra care in managing communications. You would need a combination of different types of communication here.  While you should definitely communicate overall project status to all stakeholders and higher management, it's important to keep a track of the corporate dynamics  and sync with your immediate superiors to ensure the right status and information goes out.  You may also need to be quick in responding to the so called innocuous mails coming from the customers,  or their representatives. 

2) Risk management - Risk management and communication go hand in hand.  While you need to be aware of what's happening around you and what are the approaches to risk management, you should also be communicating the risks and the mitigation plan every now and then and ensure that the concerned stake holders are fully aware of it and it's consequences. This would mean reiterating certain points in status reports, meetings, or even through emails and one on one meetings. 

3) Alternate project plans -  This comes in picture when you feel that certain part of project cannot be delivered in the same time frame due to some external dependency that is not in the project team's control. Even as you highlight the risk and communicate often, it helps to have alternate time lines or delivery approach that are possible to help deliver the broken pieces. 

4) Discipline, discipline and discipline -  This is key to deliverables. Ensure team follows process to the extent necessary even in the midst of hectic timelines. Ensure regular standups,  meetings, workflow techniques are all followed. Ensure that technical compliances are followed. Sometimes, these can become hindrances and block the delivery of the product. 

5) Flexibility - This seems to be the opposite of the previous point.  But if thought deeply, that is really not the case. While we must ensure that the team adheres to processes and standards. It does good to do away with certain redundancies when one realises that certain processes do not add any value. It's also imperative to take quick decisions and be flexible in the delivery approach, in changing the plan if needed so that the overall delivery timelines are met.

Saturday, March 21, 2015

If we plan ahead, are we still Agile?


The other day, one of the project managers posed an interesting question: If we plan well in ahead, are we still agile? And the subsequent reasoning was: In Agile, we don’t need to plan in the real sense.
I resolved his doubts and also thought of sharing the wisdom with the world.

First of all, when we talk of Agile, people have a general misconception that one has the freedom to be so flexible as to really not care about planning. Agile does not mean that we avoid planning completely, it means we have minimum and sufficient level of planning in place and are flexible enough to adapt to the changes.
Now, the key issue is how we define the minimum and especially sufficient level of planning. There is no specific set of rules or any magic formula that you can just apply and have the plan ready. It normally comes through experience. But then, there are cases when the program manager can get too minimalistic in his planning and forget to look at the big picture or the overall release goals. He may be too centric towards each sprint. And the result is that it may lead to myopic vision of the project and release. This can in turn lead to many issues arising at the fag end of the release.

The other case is when the program manager goes overboard. He sets up not only the complete release goals and sprint plans, but also meticulously plans out when the Epics need to be frozen, when the features need to be scoped out clearly, what is developed in each sprint across the various projects going on in parallel for the release.
Again, here too, I really don’t see a problem in the above set-up and approach unless the dates are hard coded and there is no scope for adapting to change in the program. If there is no scope for changes and realignment, it is as good as a waterfall model set in one of the previous decades.
A good balance can be obtained when the overall release plan is set to help guide the project managers well in advance on the approach of the release. The scope is allowed to be changed in between sprints when there are changes in scope observed by the higher executives that are crucial for the project success. The Epics defined at the high level have room for deciding what goes as minimum shipment and what goes as stretch goals, and most importantly how much of the scope suffices to make the release deliverables valid and successful.

Finally, it’s not about planning alone; it’s more to do with adapting to changes. Fundamentally, we should also remember the adage – Failing to plan is planning to fail, unless the very plan becomes suffocating and goes against the very purpose of delivering a successful group of projects in the real sense.

Friday, January 2, 2015

3 quick tips for project success


Here are 3 quick and effective tips for successful projects based on my experience in handling projects. These tips are applicable for almost all type of projects irrespective of whether they are small, medium or large. What can vary is the level and magnitude to which you apply these tips.

  • Alignment to the vision: 

Most of the time, I have observed that project managers merely adhere to their role and end up being implementers. This is not bad looking at the huge amount of activities that the project managers end up doing. But, it pays off a lot when the project manager looks at the big picture and understands the vision of the project. For this, it is imperative for the project manager to align with the management, sponsors and the customers at best. Having a good perspective of what the project would finally look like would help the project manager to plan better and provide insights on improvising processes.

  • Communication: 

This is the crux. Communicate! Communicate! Communicate! This is like a guru mantra or you can call it a success secret. It is important to communicate with the sponsors, management, the team and the customers as and when needed. Many times, I have realized that the team gives insights to the delays, risks, key concerns. However, for this to work, it is important to link communication with attitude. It is very important to collaborate with the team with the right positive attitude. This helps create a positive environment conducive for effective communication.

  • Flexibility and Prioritization: 

Often, I have observed that project managers put in lot of efforts in planning, scheduling, monitoring and controlling the tasks, executing the project activities and in project closures. However, in the process of scheduling the project end to end, they tend to get rigid in terms of following processes, tracking tasks, following schedules etc. This still looks fine in the waterfall approach, but this very trait turns out to be a bane while working on agile scrum model. Yes, following processes and schedules is a good practice, and should be adhered to a great extent. But, the project manager should realize that the whole purpose is to ensure getting the project delivered and that following processes and schedules should not be at the cost of losing out on the big picture. One should be flexible and constantly prioritize the project activities to meet the end results. Like in Agile Scrum, the stories are constantly groomed and re-prioritized prior to the beginning of the sprint. Once the sprint starts on a specific set of stories planned, it is equally important to track the progress on a daily basis and take decisions on the stories, resource assignments and priorities.

So, in a nutshell, be visionary, communicate effectively and be flexible to get success in your projects.

Friday, December 5, 2014

Having ‘Mini-waterfalls’ in your Sprints? Fine tune your Team Collaboration


You have completed a few Sprint cycles in the past 5 months, in your project execution to deliver a project or a product. Your features are almost 50% complete. You have yet another 5 sprints to go. Your sprint cycles are of 1 month each. The team is at the peak of its performance. However you realize there are still a few hiccups when it comes down to the sprint closure date, where each team feels pressurized due to the dependencies they have on the other teams.

You may think of certain assumptions when we talk of Agile Scrum.
The Sprints are ideally of 2 weeks duration.
Product Management is 1 Sprint ahead.
Development is in the current sprint.
Functional and Automation QA is 1 sprint behind.
This is usually true for a 2 week Sprint. But these assumptions might not be applicable to all scenarios.

There are projects that run on 4 weeks (1 month) sprints, where the deliverables are significant. It is unpractical to have the product owner to be ahead by a month, while the QA cannot afford to stay behind the Sprint by 1 month. It is imperative to have all the three key areas to be in the same sprint. With a slight difference that the product owner is a couple of weeks ahead, while the QA is catching up with the Automation, System, Accessibility and Internationalization Testing in the first 2 weeks; while waiting for Development team to deliver the features in the 3rd week of the Sprint to have sufficient time to test the features going in that Sprint.

However, as it happens in all projects, things don’t go as planned. There are multiple iterations while finalizing the flow or the User Interfaces because the customer had different ideas about a particular feature. (Here again, you cannot prevent the customer from intervening during the course of the Sprint). Though certain stories can move to the next Sprint. There are a couple of features that the customer is really interested to see in the demo. Development team puts in all the efforts to deliver the story on time. Still it causes delay in providing the features to the QA team.
QA team chokes in testing the features but manages to deliver it just before the demo. You, as a scrum master are continuously tracking the plethora of activities happening all around you. The team is glad that they could make it. But still there is room for improvement. But this improvement in not in terms of the typical scrum areas that we hear of. You have got an issue of having ‘mini-waterfalls’ in your sprints.

The solution to such a problem is not as simple as changing the sprint cycles drastically or moving the scope to next sprints. What needs to be worked on is how the team can collaborate more effectively.

Here, though the product owner cannot help the changes coming in from the customer, he/she can work closely with the scrum master to ensure that high priority features are addressed earlier for the customer. The business owner cannot eliminate the iterations completely using a magic wand, but can minimize the iterations by working in collaboration with the customer.

Meanwhile, it does well with the development team to closely be in touch with the product owner. The team could also benefit by collaborating the development and testing effort either by pairing up and incrementally testing the features that are code checked-in piece by piece by the developer OR by being aware of the changes that are being incorporated in the features by the developer.

In order for all this to work, it needs collaboration across the teams. This does not mean that the collaboration was missing earlier. It only means fine tuning certain traits between the scrum master, product owner, the developers and the QA team...  and the scrum master can facilitate this,  so that things work out better for the whole team and for the overall delivery of the product or project.

Sunday, September 7, 2014

Project Success: What does it really mean?


A fundamental question asked very often is what is Project Success? When do you say that a project is really successful. Many a times, you complete a project and realize that it did not add any value to the business and was shelved. Would it be still termed as a successful project? The team would have spent a lot of effort in completing the project. Definitely, the leadership needs to give kudos and a pat on the back of the project team and see how they can be re-aligned to a more meaningful project that directly adds value to the overall business objective. But this cannot be termed as a successful project.

So, coming to think of it, project success is not just about project completion on time, budget and scope. It goes beyond these three key criteria when it meets the most important objective of  adding value to the overall business success.

So, project success is more to do with the business success.

So, how does the PMO or a project manager ensure that this is happening?

One of the answer lies in effective portfolio management. This is where the PMO should be involved to understand what is the company road map and what are the business objectives. Where exactly does the company want to make investments.
Once this is clear, the Program Management team ensures that only those projects that are strategically aligned to the business are picked up. These can then be logically grouped in terms of programs.

Next, once the project kicks off, the measurement of time, scope and budget to track the project are various tools of measurement to ensure that we measure up to the business goal objectives.

Therefore, the PMO or a project manager has to be play a multi-faceted role. It becomes important for the PMO to get into the shoes of a leader. That means, the PMO should be motivating the team by connecting them with the business goals by studying the strategic objectives. Then, look at the overall progress of the project and ensure that the timelines, scope, budget, risk mitigation, procurement etc. are all met to help the project get successful that ultimately would help in the success of the business.



Monday, August 18, 2014

4 Key points to take care during a Project Kickoff

A project kickoff is extremely useful to ensure that all the stakeholders are aligned to the project right during the beginning of the project itself. Hence, if utilized well, it can reap many benefits during the course of the project. So, while doing a project kick off, be aware that it can be very crucial for most of the stakeholders who may have an important stake in the project. Some key points to take care while conducting the project kick off are:

1) Ensure that everyone knows why the project is being done. If you are working on an ongoing project with multiple builds/releases, make sure that the stakeholders are aware of what is going in that specific build or release. Ensure that the scope is clear and well understood by all the stakeholders.

2) Go through the project plan and walk through the milestones and the dates. Make sure that all stakeholders agree to it in principle and are well aware of the dependencies and why they need to meet certain milestones on time. If there are any concerns, make sure it is addressed in the forum. In case, some milestones need further discussion, ensure that it is resolved at the earliest after the kick off meeting and all stakeholders are kept aware of the decisions .

3) It is prudent to go through any additional areas that might seemingly look innocuous but are equally important. E.g., Testing matrix, Dependencies or deliverable from outside parties that are required for the successful completion of the project.

4) Make sure that some of the tasks that came up during the previous project/release that would help in tracking the project better are included and the repercussions are known. The best way to find such tasks are through earlier retrospectives or meetings done during prior project closures.