Tuesday, November 13, 2012

Making Cookies, the Project Management way

The next time when you make cookies, just observe the processes involved in it. And you will realize that it is nothing different from the processes we follow in project management.
1)      Initiating process: It all starts from Needs. This is where you decide what you need. You research on what and how you want to make the cookies based on both external and internal environmental factors. A huge product or just some homemade cookies? Put this in your project charter. You can list the following in your project charter:
a.      Initial Requirements – homemade cookies or a big product/ package,
b.      Stakeholder list – it’s for family, your girl friend or for a party,
c.       Purpose – that will determine the size of the project,
d.      High level budget – How much do I need to invest? Different budget for homemade cookies for different purposes, and different budget for outsourcing the cookies.
e.      Risks – What if the cookies are over baked? What if the guests don’t turn up, or more guests come in? What is the mitigation plan?
2)      Planning process – Now that you are sure of “how many” cookies based on the type of party/ occasion (stakeholders and purpose) (Scope), next, you decide on what “ingredients” are needed to make the cookies (Resources). What will be your “approach” to making the cookies (Overall Plan)? How much “time” will each task take (Time)? How much “buffer” do you have before the guests pour in (Contingency)? How do you manage risks (Mitigation)? How do you plan to procure raw materials for the cookies (procurement)?
3)      Executing process – This is when you actually mix the ingredients, put the dough on a cookie tray, and pop the tray into the oven…
4)      Monitoring and Controlling – Now, keep an eye on the baking of the cookies. Adjust the processes as you need. Check the consistency as you are mixing the ingredients. Keep an eye on the timer as you put the cookies into the oven.
5)      Closing – Your cookies (Product) are baked. Test to see and ensure that it tastes right (Verification). Make sure you and your stakeholders get to eat the tasty cookies (quality) on time (Deliver). Take feedback (Lessons learnt), so that next time, you can make even better cookies!!!!

 

Saturday, September 29, 2012

Scope Management – a practical approach


Scope Management – a practical approach

It is easy to list the processes involved in managing the scope of a project.

1)       Collecting Requirements

2)       Defining the scope

3)       Creating and base lining the WBS – re-base lining whenever there is relevant/ agreed scope changes with clear impact on time and cost.

4)       Controlling the scope through integrated change control.

5)       Verifying that the scope delivered is in sync with what the customer initially asked for

But, still project managers suffer due to scope creeps, unrealistic scopes, Improper Work breakdown structure etc…

What is lacking here is a practical approach to managing scope. The following tips will definitely help a project manager to manage the scope better…

Understand the vision of the project

Early in the initiation and planning process itself, be clear of the vision of the project. Go through the project charter rigorously. Understand the real purpose behind the project. If the project charter does not give enough information, contact the sponsors of the project and be sure of why the project is being done. This will help a great deal to relate to the scope of the project. It will help identify any gaps existing in the requirements, as well as any gold plating. You should also interview the stakeholders/customers that can give you more insight into the requirements the project is supposed to meet.

Workshops

This sounds familiar isn’t it. Conducting workshops will definitely help you get lots of hidden requirements that might have got missed while preparing the scope. It is also about reading between the lines and asking question to all relevant stakeholders. The best way is to ask the 5 why’s to really drill down why a particular feature is really necessary. A good idea is to use an overhead projector and let everyone discuss on the requirements. Take notes that are visible to the audience with the help of the projector. This will help make things transparent. Make sure you also clearly list what is out of scope.

Prioritise the Deliverables

This is something followed by the Product Owners in managing backlogs and prioritising user stories for a Sprint. But using a similar approach to prioritise the deliverables even in a waterfall model can give immense benefits. This will help realise what needs to be delivered first and what can be delivered at a later stage. Here again, customer involvement helps.

Work Breakdown Structure

This is the most easily understood but rather difficult to implement. It is easy to realise that the scope is broken up into smaller components that can be easily assigned with resource and aligned with the budget at the work package component level. But care and training is needed to make sure you do the work breakdown structure well and that later you are able to divide it into activities that can be assigned to resources directly to ensure that the schedule works out well.

Scope Baseline

Now, when you finally baseline the scope, ensure that it has agreement by all stakeholders and is signed off.

Monitoring, Tracking the Scope
First ensure that you would have a strong Integrated Change Control in place. Next, when tracking the scope, ensure that any changes to the scope is raised as a change request and is agreed with al stakeholders through integrated change control. In doing so, you ensure that everyone realises the impact of the scope change in terms of time and cost.

Sunday, September 23, 2012

Agile or Waterfall? Criteria demystified…


One of the major concerns across many organisations is whether to go for Agile or Waterfall methodology. Most of the project managers higher up in the corporate ladder have to take this decision. And this becomes more difficult when one has the pressure to deliver a successful project at the end.

Thankfully, there are certain criteria’s that help in deciding whether to go for Agile or Waterfall. Again the problem lies when managers tend to use it more like a cookie cutter and hastily draw conclusions.

So, the first lesson is not use these criteria’s as mere criteria’s but as indicators that guide you in the process of deciding Agile or Waterfall.

Here are some of the key criteria’s (or rather indicators):

1)      Project Scope: When we say Project scope, it is more to do with whether it is a dynamic one and is ever-changing (typically faced in IT – Software projects where the customer is not very clear on how he wants the software to operate due to its abstract nature) or whether it is fixed – (most of the construction or power projects where the goal is to build a dam of specific dimension for a specific criteria or certain fixed units of mega watt power generation capacity). If it is Dynamic in nature – you may need to go for Agile, else go for the waterfall approach.

2)      Type of Projects: Here we deal with whether the project is an experimental one (like proof of concept as in software or a drug trial experiment in pharmacy) or whether it is about delivering a product, service or idea. Dynamic projects can be better handled using Agile while others can be managed with waterfall.

3)      Delivery - how do we deliver? : This is related to point 1 and 2, based on which the customer may expect incremental deliveries in parts or may expect the whole product at the end. If the scope is dynamic, then the customer may expect frequent iterative deliveries and this will mandate for agile methodology. E.g., a software product where the customer would like to see which parts of the product is built over each iteration. Or a road construction where the road might be built part by part in phases to cover all the areas of the city. Projects where the customer may expect end result at the end would be say, a 100 MW power plant to be installed at the site and this may warrant a waterfall approach.

4)      Technology: Agile methodology is more suitable in case of projects dealing or creating new technologies. An iterative approach will help in getting continuous feedback and scope to improve. Waterfall methodology can be used where the technology is already stable and proven.

5)      Culture: Culture plays an important role in deciding if an organisation wants to go for Agile or waterfall. If the customer is active and very much involved and the management believes in self management and supports Agile, then it is easier to implement Agile. Else a waterfall approach is recommended.

 

However these criteria’s are mere indicators and cannot be applied in isolation. E.g., Point 1, 2, 3 and 4 may compel the organisation to go for Agile and then go about creating an environment of cultural change so that there is more support from senior management and that the customer becomes more active. If the customer cannot adapt, then it may bring in Business Analysts who can proxy the customer and take continuous feedback from the customer.

 

So, a better approach is to measure each of the above points from 1 to 10. Where 1 is purely agile, 10 is purely waterfall and 5 is hybrid approach of both.

Then measure each of the criteria’s separately in a scale of 1 to 10.

Apply weightage depending on which of these criteria’s are more important to the organisation.

Get a weighted average score and then decide on whether to go for agile or waterfall.
One may add more criteria’s to the above ones. Also, measuring each individually will give an idea where does one need to make changes to help implement the appropriate methodology.

Wednesday, May 23, 2012

5 Agile Myths Clarified

Having discussed about the importance of project management processes in Agile Scrum in my previous blog, let us look at 5 key Agile myths due to which scrum projects fail.
As discussed earlier, for many who are implementing Agile, they feel as if they have found a panacea to all project related problems. It seems like they have found a cure to problems such as delayed delivery, scope creep, poor quality, lack of communication with the customer, improper handling of risks and to top it all, a huge burden of conformance to processes. So, some of the agile followers are so averse to these symptoms in executing a project that they tend to delineate themselves from the basic principles and practices of project management. In fact, Agile is more about following the project management practices in a more disciplined manner…. And if Agile is not implemented in the right way, it will lead to the same problems mentioned above.
So, this gives birth to some myths about Agile and that causes the failure in agile implementation. Let’s look at some key myths…
MYTH 1: Agile methodology is all about interactions and nothing to do with processes:
Many think that Agile is lot to do with teams, collocation and interactions and that processes go out of the window. Actually, the fact is that it is not only about people and interactions, but also about following processes that are necessary and sufficient to help deliver a potentially shippable product in every sprint.
MYTH 2: Agile means no documentation:
Here again, project members tend to think that all we need to focus on is a potentially shippable and workable product and that documentation is an absolute no no. However, the fact is that one needs to maintain certain minimal documentation. Process and checkpoint documentation such as code review checklists, testing results, burn down charts to show progress and simple product documentation are inevitable.
MYTH 3: Agile means no contract negotiation:
While there is more emphasis on Customer collaboration; that does not mean that one does not have any contracts at all. In fact, contracts are equally essential. However, the main emphasis is to remove the environment of distrust and create a win-win situation for both the project team and customer through positive interaction and collaboration.
MYTH 4: Agile means no Plan:
Again, it is all about responding to change instead of following a plan meticulously. Since the whole purpose is to deliver a shippable product with good quality developed over iterations or sprints, one must not forget that it includes sprint planning. A high level Scrum or release planning is also essential to ensure that one is moving in the right direction. However, the key idea is to adapt and change rather than be rigid with excessive planning.
MYTH 5: Agile does not require PMO and HR:
This again stems from the feeling that it is all about scrum collocated teams working for the customer doing iterative development to deliver a quality product. But all this also needs various supporting elements around it from PMO and HR to:
·         Appointing a Scrum coach who has lots of experience in training and coaching the scrum teams at an organization wide spectrum.
·         Focusing on the overall project and product direction. Tracking a high level end to end plan.
·         Providing training across the organization on agile scrum.
·         Providing and maintaining templates, standards and best practices.
·         Rolling up all projects at a programme level and track the ROI for each programme to help take appropriate decisions.
·         Planning out the right career paths, reviewing compensation packages, bringing in the culture of empowered teams that can execute sprints in a collaborative environment.

Friday, March 16, 2012

Why Scrum Projects Fail?... and how to solve it?

Having discussed about the importance of project management processes in Agile Scrum in my previous blog, let us now look at the reasons why Scrum projects fail and then we shall look at the approach to solve these problems to help achieve successful Agile Scrum projects.
Re-iterating some key points on Agile Scrum… We now know that Agile is primarily a methodology to help develop relatively new complex software projects where the requirements are constantly evolving/ changing or getting added. This is achieved through an incremental, iterative and collaborative approach where quality is continuously added at every single step rather than at the end, with total user involvement to ensure the product developed at every stage is potentially shippable.
The key point in the Agile Manifesto is that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” And this preemptively defines what is meant by success in an Agile Scrum framework.
So, when we talk of the following key points in the Agile Manifesto:
Individuals and Interactions over processes and tools,
Working software over comprehensive documentation,
Customer Collaboration over contract negotiation,
Respond to change over following the plan
The success of a scrum project depends on the mindset as well, apart from the project management processes and skills.
This has a lot to do with the right mindset that contributes to scrum success and the lack of it that contributes to failure. So, when we come to think of what hinders success in scrum projects, we are primarily dealing with the problem areas around 5 key points.
i.e., Reflection, Emotions, culture, Collaboration and Adaption
No single cause makes the scrum project succeed or fail, it is a combination of these factors that make or break a scrum project. So, let us briefly deal with each of them one by one.
Emotions
Humans are primarily emotional…. We have an emotional baggage in everything that we do. The idea is to cultivate positive emotions to succeed. The same applies to Agile Scum projects as well. So, when Agile is mostly about mindset and how we approach to it, it is important that we first look at emotions, for this one area has a direct impact on the scrum projects especially when sprints are executed within a collocated scrum team consisting of at least a scrum master, designer, developer, tester and a product owner.
Emotional Symptoms that have a direct impact on the scrum project’s success or failure are
Discipline – The discipline needed for a waterfall model and scrum project is entirely different. E.g., adding extra resources or cost or time at the fag end of the project because of some delays in the beginning of the project is an absolute no no in a scrum project. It takes time for the team to deal with this kind of situation and inculcate a different set of discipline to deliver story points in every sprint to provide a potentially shippable product at the end of every sprint and demo it to the customer.
Apathy – This can happen within a team due to a number of reasons. The very fact that a team doesn’t have conventional designations and all are equal in a scrum team can lead to discrimination within the senior and junior team members causing apathy. Also, it can be related to knowledge issues where the team is ignorant or has not really understood the very purpose of agile.  Another cause of this could be the team’s prior comfort levels.
Culture
Culture surprisingly can have a major impact on the success or failure of Scrum projects. The symptoms here are micromanagement, finger-pointing, detailed reporting, and Scrum Master being made accountable for the Scrum Team. The root causes for these normally lie with the way the organization has been working in the past and the culture that has already been set-up prior to implementing Agile Scrum. These result in a hierarchical thinking mindset as in waterfall, the team believing in command and control mechanism and a scrum team formed of say members from different departments with varying compensation packages.  
Reflection
If there is no reflection on what we are doing on a day to day basis and no learning on what we have done so far with no inclination to learn something new daily, we observe symptoms such as :
Same process being followed in Sprint n as was in Sprint 1, no hands-on customer demo after every sprint, daily stand-up being monotonous and a formality, no code-reviews, and tests not run before check-In, misleading metrics.
The root causes for these are wrong value definition right from the beginning, Missing Commitment, Non-Learning, and going back to the comfort zone.
Adaption
This is again, key to Agile Scrum projects where one needs to adapt and change as one moves along in the project. While no planning is carelessness, adapting and changing the plan as one moves through every sprint is extremely crucial. The symptoms one can observe due to lack of adaption are: Sprint retrospective meetings are done without actions being implemented for the next sprint, plans not being updated due to the changes happening in the project. The Root Causes could be to do an ineffective Scrum Master, No Empowerment to the team, Invisible Product Owner or having a proxy of the proxy of the proxy product owner, too frequent changes causing team to hesitate to adapt.
Collaboration
The whole Agile Scrum framework works on collaboration. If there is no collaboration, it can impact the scrum team’s working and can thereby impact the Scrum project. Collaboration again is key to a Scrum project success. The Symptoms here are: Only BA talking to customer instead of the whole team interacting with the customer at the end of each sprint, there is no proper team planning, the proxy product owner starts deciding for the customer and so on. The root causes here are Segregation, Separation or differences within the scrum team inhibiting collaboration in the right spirit, Hard-coded Communication Paths, Push-System where tasks are assigned instead of a pull system where the scrum team members pick up story points daily, There is No Shared Responsibility, There are too much of Turf Wars or Politics.
Solution to these to make Agile Scrum Projects Succeed:
First and foremost, it is important for the organization to appoint a Scrum coach who has lots of experience in training and coaching the scrum teams at an organization wide spectrum. He needs to be a strong leader to help influence the organization to take the right steps towards Agile Scrum. This would help the organization bring in right changes in the culture, philosophy and goals that would align well with implementation of Agile Scrum. Having said that, the Agile coach would also help influence the HR, PMO and other functional departments to bring in the right work culture. This could mean planning out the right career paths, reviewing compensation packages, bringing in the culture of empowered teams that can execute sprints in a collaborative environment. The change would need to happen right from the top to the lowest level. Once the foundation is laid, every team and department needs to bring in the concept of adaption and help motivate the team members to take risks and also adapt to change more openly. All this set-up would help work in a collaborative environment all set to make Agile Scrum Projects successful.

Sunday, December 4, 2011

10 Key Steps to Revive a Project

We all talk about successful projects and discuss mostly on pointers to make our project successful. However, what if a project is already in a difficult situation? For such projects, there are some common but yet critical steps that can be taken to help revive the project back.

Projects commonly suffer from delays in delivery or overspent budgets.
The reasons for these are many. Most common are:

1)      Tight or unrealistic schedules,

2)      Unclear scope or requirements leading to scope creep.

3)      Lack of or too many resources.

If looked into or probed further deep, the problem mostly lies with communication, improper assignment of resources, lack of leadership, incorrect priorities and so on.
For this, mature organisations are already prepared with what is called a disaster recovery plan which normally consists of the following actionable and pointers. For those who are unprepared for such eventualities need to work to ensure that these disaster recovery plans are in place.

1)      Re-look at the project life cycle and processes.

2)      Re-look at the Organisational structure and restructure the organisational hierarchy if necessary.

3)      Put communication in place and in order to communicate strong positive message within the company. Understand the sensitivities of both external and internal stakeholders. This is where a lot of risk factor would be present.

4)      Ensure that the scope and requirements are clear and concise. Re negotiate the scope and requirements with the stake holders to ensure that the project is realistic and deliverable, If required, the requirements can be broken into smaller parts to help smooth project execution in realistic time scales without having the stakeholder to wait too long.

5)      Ensure that deadlines are re-visited and if it is necessary to meet strict deadlines, re-prioritise and re-negotiate the processes and the work by bringing in the Disaster recovery management into place.

6)      Ensure quality of the product, the technical road blocks in achieving the quality and completing the product/ service on time is well managed though positive and open communication and bringing in right kind of resources.

7)      Re-structure and bring in right and competent resources at key departments/ positions to help resolve the bottlenecks. Sometimes, external vendors/ or resources outside the project can be brought in as subject matter experts to work along with the existing team to enable them to get things done appropriately.

8)      Assign specialist disaster recovery project managers who are skilled, adept and can take strong decisions with their right knowledge of organisation structure, policies, industry, political connections. They can work along with the existing project manager and facilitate the completion of the project by enabling them.

9)      Manage risks and issues on a more aggressive scale and ensure that the risks/ issues are dealt with more realistically.

10)   Bring in strong leadership with qualities to help the overall project to move in the right direction, to motivate and facilitate the teams to work in collaboration, and who can usher in the right communication and guidance and help achieve the above.
One or more or all of the above steps in combination can help revive a project from disaster and convert it to a successful one.

Sunday, November 27, 2011

Leadership Skills at all Levels for Project Success


Talking about successful projects, one aspect that comes to everyone’s mind is leadership skill needed to drive the project. When we talk of leadership skills, we normally attribute it to senior management at the programme or organisational level. What we do not realise is that leadership is actually required or rather necessary at all levels of the organisation hierarchy.
Before dealing with what leadership skills are required at all levels, let us first try to understand what leadership is and what is expected out of a leader. Though, writing about leadership and its skills will itself require a separate dedicated forum and there are a huge number of books dealing only with leadership, we shall understand the key element before we can deal with leadership at multiple levels.
Leadership
Leadership is what helps the overall business objective(s) to be achieved by leading people and teams to achieve the goals by enabling them to realise themselves as part of the common goal or objective. So, from a project point of view, the ability of the leader is to guide the project team to achieve the project objectives and help balance the project constraints.
Leadership at different levels
So, there is no doubt that leadership is a trait required at all levels, so that the results are accumulated right from the floor level till the top ranks. Though, leadership is mostly discussed and referred to the top level, ironically, it is even more important at the floor level.
In general, there are some core points that leadership should address:
1)      Ensuring that the business objectives are well understood, clear and executed well enough to achieve the business goals.
2)      Communicate throughout the ranks and hierarchy to ensure that there is common direction, objectives and goals.
3)      Facilitate the team to achieve the goals by –
a.       Building the right team.
b.      Creating an environment to collaborate, communicate and work together.
c.       Motivating the team to take calculated risks by enabling a nurturing environment that allows mistakes to happen as a learning experience and improve further.
d.      Creating a positive environment of rewards and recognition where exceptional and good performance is recognised and rewarded.
These skills are generic and need to be applied at all levels. What would vary is the way and the scale to which they are applied. These are therefore even more important at small team levels which are building blocks of the whole project team and of the organisation as a whole.
Technical Team Level
Here the team lead’s role should be not only of ensuring that the project module or target is achieved, but also to create a team that is efficient and reliable. For this, the team lead should motivate the team, should keep them connected and communicate the bigger picture so they all feel part of the whole project, reward the team members and handle conflicts in an appropriate and responsible manner. He should also direct the team to follow processes, values and ethics to help the project and the organisation at a broader perspective. This fundamental approach can go a long way to not only improve productivity but also reduce attritions.
Project Manager Level
No wonder a lot has already been talked about a project manager’s leadership capabilities. As a leader, the project manager should not only process technical knowledge of handling the project, but also be well equipped functionally to manage the project well. He should apply the project management knowledge across all knowledge areas. The project manager’s personal effectiveness, attitude, personality and the ability to guide the team while balancing the project constraints all adds up to his leadership skills. It also includes how well the overall programme objectives are understood to help achieve the project objectives. This has a direct impact of letting the project team understand their role and importance in completing the project and make them feel as a part of the overall programme. The project manager should be adept at handling resource constraints within the project, in managing resource conflicts and creating a positive environment in the team.
Programme Manager Level
A programme manager should align the overall portfolio or organisational strategic direction to all related projects in a programme. To achieve this, the programme manager should ensure that all projects within a programme are achieving the overall programme objective. He/she should resolve resource constraints or conflicts at a programme level that can affect multiple projects. The programme manager should be capable of resolving issues and change management within a shared governance structure. In doing so, he/she should communicate the right message across all the project managers in his programme. He/she should also provide a clear direction to all his project managers.
The role of the PMO
The PMO or the Programme Management Office can play a vital role as a leadership team. Apart from administrative tasks such as managing resource sharing across the programme, administrating and developing project management methodologies, best practices and standards, monitoring compliance with project management standards, policies and templates, they can play a bigger role. They should facilitate in initiating leadership across the programme by being leaders as an example. They can facilitate in providing the right kind of direction, communication and team building across the programme by working more closely with all the managers. They should provide mentoring, coaching of both hard and soft skills to make better managers and leaders. They can do this by creating the right environment and training.
For this, they themselves need to be more disciplined, innovative, take initiatives, and lead by example. They can justify the PMO as a cost centre by measuring the return on investment not only monetarily but also as a creator of value addition.