Sunday, May 14, 2017

Vital signs that tells you that Scope Management needs attention in your organization

Almost all projects would have a scope defined base. Those projects that don’t have a proper scope management in place would definitely be at a peril. Though most of the managers realize the importance of scope management in the first place, they almost fail to execute it properly. Either the processes are in place, but not effective enough, or there is not enough maturity for taking scope seriously. Such organizations would normally give a fair bit of reasoning such as we are always on our toes and our project environment is far dynamic, or our resources are working day night to ensure that the customer is satisfied by providing last minute patches/hot fixes and last minute requirements.
If one looks deep into the situation, one of the reasons is the pure lack of scope management, which causes a cascading affect on unrealistic planning, poor quality of product, lots of over work and thereby causing low morale of employees.
Though there could be so many reasons/ signs, here are a few vital ones that will indicate that scope management needs attention. It could mean that the project manager would need to carefully examine and  bring in positive changes in the scope management related processes:

The team has trouble getting the project off the ground.
This is the first sign that shows that the scope mgmt related process is either not working or is not in place at all. Team members would be looking at previously executed similar projects and assuming that they would work on the project accordingly. Everyone would be thinking that he is doing his job well without looking at the big picture.
1
Number of False starts .
This is another vital sign where the project team would plan out the requirements to be done and then after a few days or weeks realize that the requirements/ scope were somewhat different than what the customer wanted in the first place. Here we go again, reworking on the scope. And after a few weeks when the team has already started progressing on  the requirements, they realize that the stakeholder had another idea. This sign also indicates that not only was the scoping not done properly, but there was also a lack of proper processes to manage the changes in scope though an integrated change control environment.
2
Unpredictable sponsor and stakeholders.
This could hit the project and the project team throughout the project life cycle. In the beginning, when the scope keeps changing every often, in between during execution and control when stakeholder would find defects as well as changes in the fundamental design and concept of the product itself; and during the end when last minute major and critical changes would creep in and shift the project completion date further to the right.

Lots of changes amounting to rework.
This is in continuation of the previous point, and it goes a step ahead when the team has no idea what will hit them next. They would have lots of unplanned work on weekends and the work would look like perennially continuing, affecting the morale of the team members and the employees of the organization as a whole.

If any of these vital signs are observed in your project, it is indicative of the scope management process that would need fixing immediately. Next, the project manager should follow the other areas of project management that got impacted as a result of the scope related problems such as time/ quality/ Resources etc.

It is important to set-up and follow the scope management processes i.e.,
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.

Tips to Conduct Successful Meetings

Meetings are normally conducted to help discuss certain problems or options and come up with a viable solution. There can be different kinds of meetings such as:
1)      Meetings with clients to sell, to discuss on strategies to provide the best service, to trouble shoot problems related to product/ service etc….
2)      Meetings with internal stakeholders within the company on project kick offs, phase reviews, knowledge transfer, and coming up with a new product, solution or approach to problem solving etc…
3)      Meetings within the team, such as team members to discuss on a problem at hand, or a review etc…
4)      Meeting with one’s own boss, boss’s boss, peers, sub-ordinates, for various purposes such as departmental reviews, status updates, appraisals etc..
5)      The reasons why a meeting can be conducted is endless.
Many professionals think that meetings are a waste of time and nothing is achieved out of it. But the fact is that it is a vicious circle created by many who think this way. There are genuine reasons to have meetings when you know that collective or subjective wisdom can help achieve the goals/solve problems and necessary actions can be taken. At least, it can help provide the right direction.
However, at the same time, I am surprised to see many executives who spend endless hours attending one meeting after another and at the end of the day achieve nothing in action. I wonder if such executives achieve any valuable results or not.
So, the idea is to have a balanced approach. I would rather advise to attend those meetings that are must and one must appropriately prioritise. In fact, there are many things that can be done by just a phone call, or just passing by the desk of another colleague and sorting out the confusions. NEVER organise meetings that is basically to solve some point of disagreement between two colleagues where rest of the participants in the meeting are just watchers. Such kind of situations can be sorted out between the colleagues internally or at best at the level of their immediate superiors in a closed door discussion.
However, in spite of all the kinds of meetings and the wisdom that surround meetings, there are some fundamental rules that can help one to achieve success in achieving the objectives for which the meeting was originally asked for.
Here, based on my experience, I have tried to simplify it and put across these fundamental points that are very useful in almost any kind of meeting. For the sake of simplicity, I have put it in three phases:
PHASE 1: PREPARATION
Anything that we do needs some level of basic preparation. Similarly, it is important to take out some time to prepare and plan out the meeting.
1)      AGENDA: First and foremost, ensure that you warm up with the most basic thing in place…. The agenda….
Ensure that the purpose of the meeting is clearly stated. This is the barest minimum you need to do to hold a meeting, in the first place. Ensure that the agenda has a topic, and clearly listed out points that need to be discussed or sorted out.
2)      PLAN: A plan is needed to clarify the purpose and the approach towards the meeting
Once you have a purpose and an agenda in place, plan out on whom all are necessary and useful to help achieve the desired goal of the meeting. The plan should also contain a venue. The venue should be such that it is by far possible for all to join. Ensure that seats and desks are available for all participants. Timing should also be planned as per the availability of all the participants, and this can at time, become daunting especially if it involves busy top executives. Finally, send out the meeting invite with clearly stated agenda, List of points for discussion, objective to be achieved, venue, time to the appropriate stake holders/ participants. If a participant cannot make it to the meeting, ensure that his representative can take appropriate decision or at least contribute ideas instead of just being a bystander.
PHASE 2: EXECUTION
1)      BASIC ETTIQUETTES: Coming on time, informing the chair person in case one cannot make it to the meeting etc..  All comes under basic etiquettes….
Imagine one going for an interview. The person would ensure that he reaches the venue before time, prepares himself well before the interview, and presents himself appropriately and so on… In fact the same rule lies when we all come for a meeting.
2)      EXECUTING: Ensure that the meeting is used for discussing the right points as in the agenda and uses everyone’s time in a productive way.
For this, it is important that all participants’ points of view are taken into consideration, everyone gets the chance to talk, and that ONLY the relevant points are discussed. Any one deviating from the objective should be respectfully asked to stick to the agenda and that any new points arising can be discussed at the end of the meeting (if time remains) or in the next subsequent meeting. Ensure that minutes of the meeting are maintained by a responsible and identified person. MOM should not be assumed to be maintained by all participants. Ensure that arguments and quarrels are kept aside and if any such incident is seen happening, are immediately mitigated. Once the duration of the meeting is coming to a close, give gentle reminders to ensure people wind up quickly.
PHASE 3: CLOSING & POST MEETING
1)      Closing the meeting: This should be done by  summing up what was achieved in the meeting, on action points and future follow up meeting date (if required)
Here, ensure that the objective achieved is measured and stated. If any agenda is left pending, check if all the participants have any additional time to pick it up, else, arrange a next round of meeting to pick up those. All actions along with their owners should be summed up to prevent any ambiguity on who is to work on what. Please don’t forget to thank everyone for their valuable time and effort at the end of the meeting.
2)      Post Meeting: Distribute the MOM and the actions, with a clear list of their owners. For this, it is a good idea to use project or organisational process assets to maintain the meeting details, actions and history in a centralised place accessible to all who attended the meeting or those who will be affected by the outcome of the meeting. Send a separate invite for the next round of follow up meeting with the updated agenda, venue, time and participants.
Hope you all derive benefit from these tips and make your meetings more successful.

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.

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.

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 cultureThis 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.

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.

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.

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.

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!!!!

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.