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.

Sunday, June 1, 2014

Is the team really working on your project?

Most of the time, we face this question while tracking our projects.
“Are the team members really working on the project so as to complete the deliverables on time?”
 If not all, the doubt comes when we observe a couple of team members giving a positive status but we do not see substantial progress in the project plan. Many a times, we are usually not equipped with handling such a situation and end up with a devastating situation when it comes to delivering at the end of the project timeline.
Before we discuss on the real scenario solutions, let us first look at what causes such type of a situation and what can possibly resolve the problem.
First, it boils down to the type of organisation. Is it a matrix based organisation and are some of the team members reporting to a functional manager? If yes, you are likely to have a situation where the team member may actually be working on some other priorities for the functional manager while his assignment to the project would be more on the face value. The team member cannot help but keep his functional and appraisal manager happy and may just be “managing” the work of the project assigned. In this kind of a situation, it makes sense for the project manager to deep dive into the situation. There are different approaches that can be used depending upon the organisation. One suggested approach is to check with the customers on the deliverable timelines and quality. Then, take the feedback to the appropriate senior management and/or discuss with the functional manager. A constructive dialogue often sets the right expectation and the team member can better prioritise the tasks. If the problem still persists, it might require to escalate to the top management and hard decisions to be taken.
Second reason could be if the project has just started and say, you are in the first couple of sprints. Here, you may not even have detailed project tasks cut out. In this case, it is imperative to get more insight into the project task details. Ensure the assignments are clearly made to each of the resources. This would ensure that no one just gives a vague status and then unnecessarily building up the pressure of non delivery at the end of the sprint.
Third key reason can be the limitation of the project manager to confine to the boundaries of tracking only the task statuses, resulting in the scope and functional requirements being solely managed by the product manger or the Business Analyst. Though, the project manager cannot really take the role of the BA or the product manager, he should definitely understand the product functionality to help appreciate the scope and deliverables. The project manager should be able to align the functionalities with the business goals.
The project manager can then be able to do better justice to the project deliverables and be able to appreciate the role of each team member in the overall project execution.