In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.
1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.
2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.
3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.
4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.
5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.
6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.
7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.
8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.
9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.
10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.
Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.
So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:
5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.
4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.
3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.
2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.
All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.
The Post implementation review is usually filled collectively by customer project team and signed by the project sponsor, who is usually one of the senior members of management. This form is to be submitted back to vendor (after filling) to serve the purpose of – sharing experience, product evaluation in live scenario, user’s satisfaction, assessment of management itself in understanding the goals assumed or perceived versus the actual goals achieved. The components of this review and WHAT, WHY and WHEN have already been discussed in earlier posts.
Let us now understand – what are the guidelines for management (customer), project team and key users for filling in the Post Implementation Review:
This is not a sports match: The project should not be taken as a sport match where one has to be declared winner and the other loser. In a software project either both teams win or lose. So intention of the review should be taken in right spirit and with right approach.
Be Courteous: Don’t be too blunt while filling in the replies. It could hurt the sentiments of vendor. After all if something has gone wrong, it needs to be analysed and resolved rather than throwing stones at each other. Remember that someone had made a choice at your end for this product and that is why it is here. On the other hand if all has gone well, be generous in praising.
Don’t be a critic: Don’t analyse this product with a critic’s eye. Your goal while selecting this product was that you had a trust in the vendor and this product. Evaluate more on the basis of your key user’s confidence, satisfaction, results, improvements, and product strengths.
Be Transparent: It is good to be courteous, non-critical and not-blunt. But don’t shy away in exposing any weaknesses in the product, the methodology adopted, trainings imparted, or vendor’s team efficiencies. Strike the right ball in right hole at right time. After all it is learning for both the vendor and customer that is helping in product and people maturity.
Ask for more: If you are happy with the vendor, don’t hesitate in asking for more features or functionality (may be as a bonus, if you are able to pamper the vendor enough!)
Both vendor and customer have to understand that the real journey of a product starts only after a successful implementation of software at customer site. The challenges get a new meaning once the project team leaves the customer site after project sign-off. Both the managements can celebrate the successful completion of project. But it is better to hold on this celebrations for a while, till customer really learns to live with the product, starts tasting the real fruits of the product committed earlier. Let the key users start managing the show on their own, run the complete process in live scenario and get satisfied with themselves and the product. The project team that comes at customer site for implementation has a role related to post implementation review prior they go back home after successful closure of project. Similarly the management (customer) have to clearly understand their critical role once the vendor project team goes back after the completion of project. It is the key users and management (customer) now to run and manage the show. No doubt that the vendor team is always at the back to support and assist them in achieving this. Let us assume that the project is over and team is about to leave the customer site. At this juncture it is the prime responsibility of vendor and customer project managers to shake hands and understand the importance of post implementation review in following terms:
The Project manager from vendor side has to hand over the post implementation review plan to customer at the time of implementation sign off and explain clearly each and every agenda of the post implementation review. The clarity in terms of product, managements, users, usage and product is very important for assessment purposes after a stipulated period.
The project manager from customer end has to ensure to get the post implementation plan for feedback purposes at the time of implementation sign off. This will not only leave the project open for another some time in terms of providing a lease for customer team to assess and experience the product in complete isolation in their own terms.
The purpose ultimately is to share the overall health of product, the key users, and the management.
What is post implementation review? When it should be done? Why is it required? All this has been discussed in last three posts. Let us now understand what ideally would be the components of a post implementation review. As discussed earlier, some components can be answered immediately at the completion of a project with a formal closure. But for answering some other components, customer needs some time for project to run in the absence of project team, experience it, feel it, see the user’s reaction on the way things are happening in the product when it is in use.
Infact before filling the post implementation review, it is advisable to use the software at its maxima, as extensively as possible, involving all key user’s areas, using all inflow and outflow procedures. The basic guidelines required while filling a post implementation review can be take up in my next post. Let us also understand that this questionnaire has to be quite elaborative and descriptive. Let us first understand the essential components of Post Implementation Review for a software project. The questions can be built as per the need of the vendor and product. The essential components to be covered are:
1. Effectiveness of the Project Team
2. Effectiveness of Customer management in managing Product understanding and implementation
3. Effectiveness of Customer management in understanding the requirements, building the product, selecting the right team and procedure
4. Change management during the complete cycle
5. Issues management
6. Preparedness of key users and management for accepting the product
7. Communication skills and management of vendor team and management
8. Risk perception, risk management
9. Product effectiveness, usefulness, maturity and friendliness
10. Customer management eagerness for future business to the same vendor
These are the core components based on which the elaborative questionnaire can be build to assess customer satisfaction over the product, vendor and team.
When is to perform a post implementation review? A witty answer could be – obviously after implementation. Ha! Definitely a successful closure of implementation could declare a project closure with a formal project acceptance report or project sign off. So shall we have a post implementation review as soon as we have a project sign off? Nah! That would not solve the purpose. Give an appropriate time to the customer team key users to settle down as the captain of the ship and sail it smoothly. One day or one week smooth sailing will not tell you the turmoil or undercurrent storm about to come in future. Correct. Then future is too long. That means keep waiting for turmoil. But mind it, all ships sailing in the sea do not experience storm. Similarly all products after implementation and project sign off do not guarantee a serious disaster.
Product performance in actual sense requires a certain timeframe to establish and to give confidence to end users. Some part of post implementation review related to team performance (implementation) can be answered quickly, maybe immediately after the project closure. But the other part needs a considerable amount of time to understand the product from different perspectives and accordingly present a right picture in the review report.
Certainly, then, atleast a period of minimum three months is required to experience the product and then fill in the post implementation report. Ideally, I would say, wait for six months, use product in all respects, aggressively, and then the top management need to sit with their key users and project board to evaluate, assess and fill the post implementation review.
A successful implementation does not ensure the completion of project. The reality starts when the implementation team has gone back and users have started using the project in full swing with the help of training material, learning, knowledge and product. The health of users in respect of using the product is sustained, deteriorated, or improved will depend on many factors. A post implementation review is always important to understand the users understanding, pains and delights during this tenure. This will translate further into management’s pains and delights. The overall delight weightage has to be higher than the pain. In a blow of project implementation phase users might feel quite confident regarding the product features, functionality and ease. When the whole thing falls upon them, it usually drive them in confusion, wrong actions or stoppages. Or a smooth drive.
A post implementation survey will help in a real measurement on two fronts. One front will be users’ understanding, ease and comfort (or vice versa). Second front will be product’s stability, performance and functionality. It also will assess the after effects of a successful project implementation.
The conclusions could be misleading although and will require a deep analysis. A user’s lack of understanding may spell into products inefficiency or the opposite of it.
A Post implementation review is conducted after a substantial period from implementation sign-off. This review is to ascertain customer management’s and users’ experience on product in absence of product implementation team. The product has been implemented successfully and the team is gone. Ofcourse sufficient learning, knowledge, exposure and material have been imparted to users by the implementation team.
Post implementation review by the customer management with key users will spell out – user’s depth in using the product and product’s reliability and stability. The format of post implementation review document should be designed by the vendor management for the purpose of understanding the status of project after a certain period of usage post successful implementation. Filled by customer management in agreement with key users’ experience, the report is sent to vendor for their assessment.
As stated in previous two blogs, top level expectations gathering is very crucial during the business study and requirement gathering phase. And respectively I mentioned how vendor and customer can be careful (and should be) about that. Although it is rare and unexpected, but there are instances where customer organization top level management may not involve in a new software development project. This could have various reasons but could lead to only a single road – where the end is DISASTER. If this so happens, the chances of project getting hurt are manifold. It will precisely and ultimately lead to project failure. The reasons could be many, but to my mind following come at the top:
1. Customer Top management presumes that their involvement requirement is only for signing agreements, papers, reviews and sign-offs. If that so, they will have almost negligible awareness that how critical it is for them to get their expectations and requirements (top level) during requirement study phase. After all it is an investment of time, resources and money. Instead of getting a jolt at a final stage about getting the unexpected or not getting the expected, it is better to explain right in the beginning their own requirements and expectations from the product in detail.
2. Vendor’s management role is very crucial during this phase. They have to take initiative in explaining the top management about the benefits of the product being proposed. How it is going to enhance the processes in the organization, the change in roles etc.
3. Assume a situation where there is a pressure from user level for a solution or a product at customer end. The management is not sure about the product. Without horizontally analyzing various solutions available, they decide to go for a particular vendor or product just for the sake for fulfilling requirement. Although it will be rare, but even it is there at a very low intensity, it need to be addressed.
4. Customer top level assumes that the solution being invested into is meant only for user level and not organization level. This is a wrong assumption. Any investment – small or large- has to have benefits for the organization and top management on the cards.
5. Customer top management overestimates their users and assume that they will be able to drive the project without top management’s involvement. This does happen but very rarely, in very organized structures.
Usually it is the customer top level person who is project sponsor for a software development project, be it in-house or from a software development vendor. A Project Sponsor may presume that his/her roles during the project would be – sign agreement and papers, assign roles down the line for the project, monitor/review project at various stages etc. A critical and crucial role is overlooked that of getting into the project especially during atleast vendor’s business study and requirement gathering stage. It is not only important for project sponsor and directors to be part of this stage but equally important is to involve all top management in that.
In brief, Customer Top management has to fully understand the benefits being proposed by the vendor that will be produced by the software when it is in use. They should also participate fully in business study and requirement gathering meetings to define and freeze their own expectations from the project/product/software/vendor.
The most critical stage in software project lifecycle is business study and requirement gathering. Vendor has to be very cautious and careful in understanding all levels expectations from the product they are going to build for the customer. Skipping top level at this stage could be disastrous for both. As a vendor, if you don’t involve customer top management while gathering requirements – you are inviting a mishap!
Customer top Management involvement is very critical during the business study and requirement gathering phase of a software project. The expectations of top management shall invariably be different as compared to other stakeholders of the software project at customer end. Assuming that the requirements gathering from process owners or end users will be sufficient for developing software will be a misconception. A detailed discussion for capturing requirement and understanding top management perception is critically important to lead to a successful completion of the project.
At the Vendor end – the Project Manager has to ensure that besides capturing user level requirements, it is essential to highlight the benefits to the top management being proposed for them from the product. It is not desirable but mandatory to freeze top level expectations at business study and requirement gathering stage.
Scope defined and decided upon initially by vendor and customer mutually has a large impact on timeline, progress and success of a project. A change in scope at a later stage may call for a big impact on project schedule and progress. Let us see the roles of vendor and customer respectively in this aspect of project.
Vendor – Project Manager has to ensure that the scope of project defined in the Business Study Document has to be adhered to. Any change in the scope (increase or decrease) has to be escalated to both the managements and the project plan has to be re-designed thereupon.
Customer – The management and project manager has to ensure that they define the Right scope for the project (number of locations, pilot site etc.), also understand that any change in scope will adversely effect the project plan and hence seeks redefinition. The pilot site chosen should be the best possible site in terms of testing the software completely and rigorously.
Sign-off at various stages has a significant importance during project lifecycle. Everyday sign-off can be a headache for customer, no sign-off can cause headache for vendor, so there has to be a balance of sign-offs of milestones, achievements and stages of project so that the sanctity of sign-offs is retained thereby earmarking the progress of project. Both, vendor and customer have to be very careful in this aspect of project management as it is crucial for all stakeholders.
At Vendor side the Project Manager has to educate the customer management and project manager over the benefits of timely sign offs. Sign-off should not be there just for the sake of it. It should add substantial value to the project.
At Customer end the Project Manager and management should respect the timely sign-off practice but also ensuring that the activity which is being signed off has finished in actual, rightfully and rightly.
Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.
At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.
At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.
Although it can not be avoided in real life scenario and that is why there is a risk plan and risk management to avoid such circumstances. But still a lot can be done to atleast minimize the risk and thereby mitigation.
Vendor – Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and team members during the project lifecycle.
They also have to ensure that the project is handled in such a manner that any change(s) happening therein will not affect or delay any of the stage.
Customer – Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and key users during the project lifecycle.
They also have to ensure to adhere to the guidelines specified by vendor project manager to manage such change(s) so that it does not affect or delay the project during any stage of the project.
Project initiation starts with the marriage of vendor and customer to produce the desired software product. The desire comes from customer, with a promise from vendor to deliver the desired product. The time and investment (in terms of people, equipments, and expenses) calls for a superior quality management so that the product can be built as per requirements and in time. Project can be managed well with the best possible project management practices.
There can be two scenarios – the customer is already having best practices in place and in that case asks vendor to follow those practices as these practices have already produced desired results in past. That means the practices are well established at customer end. The other scenario can be that customer is not aware of any best practices and looks at vendor to follow as per their standards set for other projects. In this case the vendor has not only to bring those practices in place at customer’s place but also primarily educate customer about them.
That means the role of Vendor Project Manager will be to design the best practices suited for the project and educate the customer management and project manager to adhere to those practices. He also has to highlight the benefits that will be coming out of those practices.
Customer Project Manager and the management, on the other hand, have to understand the practices designed for the project and ensure their adherence at all levels.
Project management is a joint effort of vendor and customer teams. Project Organization members have to play their respective roles timely and religiously to get the best of the results. Both have to go hand in hand right from the start of the project till end and even beyond. The relationship does not end with the successful completion of the project. Rather a new journey starts with the project sign-off. The baby borne by the vendor team with the help customer team changes the hands with the project sign-off. If these responsibilities are not well understood well in advance, it may lead to overrun and may end to the total failure. To avoid a project overrun the vendor and the customer have to trigger the alarm well in advance as soon as they sense a sign of overrun arising out of any reason.
At Vendor end the core responsibility of project manager is to train the customer project manager in project management so that customer project manager takes the lead in project and ensures that there is no overrun in terms of time and revenues.
At Customer end the customer Project Manager has to be pro-active in his approach to escalate the matter to his top management in case he feels in advance that project is going to overrun (with reasons identified and agreed upon mutually). Some suitable metrics can be used as project plan to trace the progress of the project in accordance with the project plan.
Project overrun is not unknown for any software organization. Every organization who has tasted it would acknowledge that it is always painful – in terms of time, cost and resources. Ultimately when the other two factors are also converted to cost, it comes to a voluminous figure. Nobody wants it, but in many projects despite all good efforts it becomes unavoidable and then some valid reasons are listed to justify it. Usually as the project overrun starts – simultaneously starts a hidden tug of war between the vendor and the customer.
Customer gives a different set of reasons all pointing towards the vendor to prove that it is the vendor who is responsible. Vendor on the other hand tries to justify that there were n number of shortcomings at customer end that caused it.
And that becomes a major cause of more overruns… sometimes endless…
Instead even at this juncture, when an overrun starts, if both the parties sit together and find out the root cause instead of finding out reasons to blame each other, it would be helpful in stopping further delays.
A classic scenario happened in an organization recently as told to me by a project manager of that organization engaged in software development and implementations.
It is related to project overrun.
A new project started with a set of requirements from a customer for development and implementation. It was an overseas project so project cost was comparatively higher than the domestic project. The respective teams for business requirements, development, configuration and implementation were formed. All went well till the implementation phase. The implementation team was ready to take the charge for on-site visit with the product to launch there.
The implementation phase planned was 4 months. Somehow due to a mix of reasons, it took 18 months to complete the implementation.
The team came back after successful implementation. The customer paid the full project cost as was accepted upon in the beginning.
The project was declared as successful without any overrun. For overrun cost was taken the criteria and since full cost was recovered, it was treated as not overrun project.
Is that right?
Throwing some points to ponder upon:
The cost that had to come 14 months back came now.
The team that has to return 14 months back arrived now.
In this period of 14 months atleast 3.5 projects of similar nature and size would have been completed.
The project manager is over-optimistic.
Project monitoring was very poor.
Project overrun is simply a project crossing its boundaries set by the organization. These boundaries may vary from organization to organization depending on how they blindly or how over-extensively (both extremes) they want to look at it.
5 ways to control project overrun could be:
2. Customer engagement: At customer site (or earlier as and when customer involvement is required) if customer project team is not justifiably involved in project by means of specifying requirements, providing master inputs, in training, timely sign-offs at various stages, hands-on exposures, etc. effects project drastically and plan may go haywired, without anybody’s accountability to prove, if alarm is not raised well in time.
3. Milestones: If appropriate milestones are not identified and monitored at every stage of the project, it affects the project finish off in time.
4. Management involvement: If management let the project go off without their involvement in it, it has high chances to overrun.
5. Celebrations: No celebrations of achievements during the project can decelerate the tempo and momentum of the team at both ends to finish off the project in time.
All projects are prone to overrun. An overrun acceptance is directly proportional to an organization’s fault absorption capacity. Accordingly the definition of overrun is framed to demonstrate an overrun project as rightly completed project.
5 myths about Project Overrun could be:
4. Manpower: Project Plan is made after which additional manpower is inducted in the project, but no need to revise the plan.
3. Cost: Customer is ready to pay the full payment to complete the project, even if it overshoots the timeframe decided as per plan.
2. Time: A project had to complete in 5 months, but it took 10 months to complete. Imagine the manpower engaged in this project that could have finished another project if this project finished in time.
1. Customer: Customer is not able to cope up with plan but not ready to pay for extra efforts being done by the project team on behalf of customer thereby overshooting cost and time. We have a valid reason for this overshoot.
The customer project manager has to take the lead and ownership of product as soon as it is launched at customer site for implementation. The UAT, training and implementation process can only be effective in case customer project team gets fully involved into each and every activity of the implementation phase. Infact the implementation plan prepared by vendor project manager should be the responsibility of customer project manager to execute.
Customer Project manager and management has to clearly understand the risks involved during the business study, implementation and post implementation phase as highlighted by the vendor Project Manager and to act thereupon to overcome those risks with suggestions from vendor project manager.
These risks could be in terms of consequences involved:
the involvement of users and process owners during business study, implementation, UAT, masters creation, transaction entry, reconciliation etc.,
if sign-offs not happening in time, etc.
Even if the sign-off is given and product is not put in use, there is a chance of project failure at both ends.
He has to make the customer management totally convinced that it is their product which they have to use in real life scenario and hence they have to be fully confident in that. The vendor management has to be with him all the time for this.
Project managers (the customer end and the vendor end) have to work hand in hand during the implementation stage of a software project happening at customer site. The key responsibility of both the project managers working on the project is to ensure successful implementation and project closure.
It is the customer project manager who has to take the charge, be in full lead and command to drive the project and keep the responsibility and onus to him and his management. The implementation plan has to be his baby all the time. Unless and until he takes the lead, he will not be able to put the potential fire in his team to accept the product. And then only he will be able to ensure a fully hassle free implementation.
No project manager can claim there was not a single problem in any of his projects. But then he is to tackle them. To tackle them he should be aware of them. To be aware of them, he has to have an ability to foresee them than to overlook them. The earlier he envisages those problems, the more time he will get to dig into and find out a countermeasure. No software project is problem free, but then… the project manager has to be alert and have a perfect vision to oversee them, accept them, plan accordingly and win over each of the issues.
Problems will definitely be there, in all phases of project lifecycle. It is the vision that you envisage them in advance and prepare yourself to overcome them.
The deficiencies do not get so highlighted during in-house development and testing phase of the product. But it becomes prominent any problem that arises at customer site during the implementation phase, or say post implementation period.
It is not only the project manager but all stakeholders who get affected by the project over-run or failure. It could happen due to any reasons. One of the major reasons that have emerged is the lack of vision of the project manager, project sponsors, project directors and other stakeholders to foresee the problems faced by customer during implementation or post implementation while using the product.
The product may have been developed well, tested well and built well to launch, but what happens if some soft issues that may arise during implementation or even post implementation period are overlooked. It could lead to a disaster…
A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.
Let us understand the different stages of risk in software application development and testing phase:
2. Risk identification
3. Risk Assessment
4. Risk Analysis
5. Impact Analysis
6. Risk Classification
7. Risk Plan
8. Risk Plan Analysis
9. Risk Plan Execution
10. Risk Closure
Similar to SDLC (software development lifecycle management), there is RLC or Risk lifecycle management in a software application in which there are different stages involved. The different stages could be risk identification, risk assessment, impact analysis, countermeasure identification, countermeasure assessment, risk plan etc. There are certain facts about Risk:
2. All risks have an impact: All risks have an impact – large, medium or small, but they have. It is the impact that makes its severity high, medium or low and accordingly a plan is prepared to handle the risk, when it happens.
3. Same risk in different circumstances will have different impact: The same risk will vary in terms of its severity under different circumstances of usage, user base, geographic location, type of application etc.
4. No application is 100% risk free, whatsoever countermeasures are taken for it, and only thing that gets done with the countermeasures is lowering of risk: A risk plan to countermeasure a risk never fool-proofs a risk’s impact, only it helps in lowering its impact to a certain level.
5. Risk Impact Cost vs. Countermeasure cost: It is very important to have an analysis of both before deciding on the plan. Some risk may be very severe but its countermeasure cost could be unaffordable.
6. The biggest risk in any application is identification of wrong risks, impact, and plan: Identification of wrong risk with right estimation of impact and countermeasure is useless. Equally useless is identification of right risk with wrong impact analysis (thereby underestimating or overestimating the impact) and arriving at a wrong countermeasure. Right risk identification with right impact analysis but with wrong countermeasure also is a waste of efforts.
Any activity is never without risk involved in it. Risk could be classified in different categories like – low, medium or high depending on its impact, software’s requirements and purpose, software usage, and software user volume. Accordingly the risks are identified or rather perceived. Their impact is measured or assessed, and based in the category in which it falls into – its countermeasures are designed or defined. The right identification of risk is as important as its classification or category.
A classic example could be a bank application being used by all its customers for their account maintenance, for transactions and for various other purposes. The risks involved in this sort of application could be: availability of application to all its users all the time, the speed of the application, the security of transactions, the ease and comfort of usage, the user account vulnerability of hacking and so on.
Some applications required all time availability whereas other demand high performance and high availability at peak time. Say, for example there is a website of a university where the peak usage is only at the time of admission or enrollment, at the time of fee payments, and at the time of release of results. At these times the volume of this site usage will be extremely high. So not only it demands availability of application at critical or peak times but also to be ensured is that it does not crash down due to high volume of use.
So it is very important to identify the right risks, to understand the right impact size, and to derive at a right countermeasure.
Once upon a time there was a programmer, a very good programmer. Good here means skilled, learned, experienced, and serious. He was appointed by an organization for a large project for a job to write quality programs. He was doing it well and was able to prove his point that he is good for the purpose he has been appointed for.
All of a sudden the large project was required to be closed. Now, the good programmer had to be absorbed in some other project, as company was in favor or retaining him. He was moved to another project requiring different platform development skills. The development platform is different than the one on which he was working in the previous project. He was master of this platform also and assured the management that he is fit for this new requirement and would be able to deliver well as he was (in his earlier project).
But somehow, his new project manager started feeling that – he needs lot of spoon feeding, he is not very productive and is quite slow in delivery, he is not self driven, he is not enthusiastic enough and does not report well.
Would someone like to share – who needs to do what in this case?
Let me start with the classic story –
This refers to the team of a Project Manager. The team size may vary from project to project and organization to organization, but the story remains the same. Story is quite short and interesting. A Project manager assigns different set of tasks to his team on 5 members individually. Each member has to start the work on Monday morning and finish it off by Friday evening. One member finishes her all assigned tasks on Thursday evening (without compromising with the quality of work), goes to her project manager, reports about the completion of task and requests for an off on Friday with a genuine reason. The project manager refuses although he admits that the work is complete, it is quality work, and the reason for seeking off is also genuine. The reasons for not sanctioning her the day off given by him were – it will spoil the culture and discipline and it may lead to non-quality work production. He was more into favor of her sitting with other team members and helping them in finishing off their individual tasks.
Well said, but this is only one side of the coin. Although project manager trusts all team members but out of fear he is not ready to do a favor to one member as it may spell out wrong signals for others.
But has the project manager understood that there are always HARE and TORTOISE in a team. All have just one responsibility – finish their task in assigned timeframe and produce quality work. It is not HARE’s responsibility to help others. If HARE is able to finish off her tasks earlier than stipulated time, it is a credit and she deserves a reward for that. And above all what about her trust getting hurt and she getting demotivated by not getting a reasonable favor.
I am sure, the reader would have their individual opinion on this – would love to hear!!
Due to recession, there is scarcity of business and projects for software organizations. In such a situation, the projects in hand (and the forthcoming ones) have to be handled very carefully for a win-win situation. To attain that, there are certain smart weapons that a project manager needs to be equipped with which will not only make him and his organization a winner but would definitely have an edge over the competitors to acquire more projects. The weapons are well tested based on experience, knowledge and wisdom.
The 20 most powerful and smart weapons can be listed as:
2. Be Sincere and frank in your meetings of all levels
3. Maintain and demonstrate a sense of mission
4. Work hand in hand with your peers – quality manager, development manager etc.
5. Be convinced of the trust between your product and quality
6. Let your team feel the weight of responsibility
7. Plan your course of action on all issues to avoid a crisis
8. Listened attentively to every word of your customer demonstrating great sincerity towards product and customer
9. Have strong interest in quality issues
10. Be highly knowledgeable about your product
11. Your Product and Quality (with your technological prowess and their quality strengths) must work together
12. Higher is the rate of dependence on Quality, higher is the success rate
13. To avoid major problems never leave a problem unresolved for tomorrow
14. Thinking, Innovation, Brainstorming are good tools if used regularly
15. Always have common awareness of all issues, so that your discussions are of highly substantive in nature
16. Be a linchpin (A central cohesive source of support and stability)
17. Consider customer requirements as “cornerstone” throughout the project. (The fundamental assumptions from which something is begun or developed or calculated or explained)
18. Build a culture of putting fullest sincere effort by everyone in the team(s) (vertical and horizontal).
19. Maintain a continuous gently-ascending approach (act of changing in an upward direction)
20. As a bearer of the highest level of responsibility reaffirm your determination to safeguard the organizational interest and ensure the best of the results
A new entrant at any level should never be burdened (leave aside “overburdened”), and an ample time should be given to him to prepare himself for the forthcoming project(s). If already there is a load of work, the minimum should fall on the new entrant, rest should be shared among the existing team members. This is to avoid any shock states for the new entrant and moreover he should be given ample time to groom, adopt, accept, learn and understand.
Simple theory is that a plant that has to turn into a tree later can not bear fruits in its plan phase. No wonder if extra burden is put on the new entrant – either he will run away, or will break down. The plant will require proper care, protection, air, water and atmosphere to grow, which becomes the responsibility of the team leader, project manager. A guideline for this should already be there in place through the top management which gets into the culture of the organization and in turn in the heart and blood of the existing team members.
Usually during the period between first project close-out and next project initiation, most of the team members of project have not much to perform except utilizing their time in non-visible activities. This could include personal web browsing, social sites, pending emails, thinking about improvisations, learning from past etc.
In an organization, management has to understand that if some of the teams of team members are sitting idle that does not mean they are useless. That means that they are undergoing revitalization phase. Surprisingly you will notice that by allowing teams/members to sleep at job when not at the peak of a project will generate an extra bounce of energy which can be utilized at the time when they jump into a project, especially when on a remote site during implementation phase. During this phase most of the team members don’t bother about time and pay their full energy into completion of project in as best possible manner as they can. And probably that energy, zeal and feeling comes from that period when they are allowed to relax.
All project managers depend on their teams working on the project and in turn the persons who form the team. Teams could comprise of project leader, module leaders, functional consultants, technical consultants, database architecture, system designers, developers, programmers, testers etc. To keep working towards excellence a project manager has to focus continuously on people management, grooming of teams and team members.
If project manager’s has this as one of the top priority in his list then his performance, the results related to his project, and his team’s momentum are always improving. The top management and the project manager have to clearly understand that what it makes to run a company and project successfully is not anything else but the people constituting various teams.
In software project there are two key agencies involved – customer and vendor. Both have to own equal responsibility in managing, monitoring and completing it successfully. In my earlier blog I have mentioned 6 mandates for Vendor Organization on Software Project Ownership. Here I would like to highlight 7 mandates for Customer Organization on OWNERSHIP in a software project. If both these mandates are followed, there is not doubt about the success of a project.
Mandates can be as below:
1. Involvement of top management during specifications finalization and implementation is mandatory: Most of the times customer management thinks their role only in signing off the project initiation documents and after that they feel it is the responsibility of the vendor team and their organization team managed by respective project managers to run the show and make it a success. This is a wrong concept, as the top management has to play a lead role in defining their expectations and requirements during specifications finalization phase of the project. They have to keep monitoring the progress of the project in later stages too. Generally what happens is that the top management do not define their requirements and expectations during this phase and at the final stage of implementation they feel robbed off as they realise that they are getting nothing or something they did not require or expect.
2. Project Manager and Key users should be identified well in advance and should be spared from all other responsibilities during requirement freezing and implementation phase: The top management should identify the project manager and key user well in advance based on their business knowledge, process ownership and commitment towards the organization. They should also ensure that this team’s top priority is now this project where they have to define specifications of requirements, UAT, implementation, reconciliations etc. And if they are engaged in their day to day routine activity or in any other critical program, they would not be able to do the full justification to the project.
3. Management has to ensure all milestone sign-offs – like requirements study, UAT, Implementation close-out etc: The management has to ensure that they mutually identify the milestones of the project. Proper sign off after each milestone achieved, monitoring of milestones progress etc. The persons understanding the gravity and seriousness of the matter should be authorized for signing off the various stages.
4. Project Manager has to ensure about the specifications completeness and validation during requirement freezing phase. Also he has to ensure his own and the key users’ availability during the project implementation, training and UAT phase: The project manager chosen by the top management has to ensure that accurate and complete requirements being documented validated by respective process owners. Since top management can not be involved in day to day activities of the project, he, being the project manager has to raise an alarm to the top management as and when he foresees any deviation from the plan or unavailability of key persons of his team who have to define the requirements or have to vet the validity of software meeting those requirements defined.
5. Project manager has to ensure the adherence of implementation plan timeline and any non-adherence has to be escalated well in time: As said above, Project manager has to be very careful and serious in this regard, and should be empowered enough to raise the appropriate alarm to the right person at right time at any level.
6. Top management has to review the progress of the project regularly as per schedule (weekly/daily): Top management has to have a process to monitor the progress of the project. The metrics could be plan vs actual or anything. Their involvement in monitoring the progress will definitely keep everyone in the team on their toes.
7. Persons dedicated for requirement freezing should be well aware of business practices, processes and statutory requirements of their organization and country: This is very important but not critically analyzed often. The persons identified for defining the process, requirements and business rules should be well aware of the business practices and processes of their organization and any statutory requirement of their country.
Ownership is a big issue in a software project. Customer organization assumes that since they are spending money, it is the sole responsibility of supplying organization to make the project a success. Vendor organization on the other hand assumes otherwise. Who is right? I think both are wrong at their ends. A Project can never become a success while the two agencies involved act as separate islands. Both have to take the equal ownership to make it a success.
The six important mandates that a vendor organization should follow in that regards can be listed as below:
1. Involvement of top management is mandatory: Involvement of top management of the organization engaged in development of software product for an external customer has to be involved in the complete project lifecycle to make it a success. This does not mean a day-to-day involvement in monitoring the progress but there should be some metrics to monitor the overall progress at any moment of time. Another aspect is involvement of top management gives a serious impact on the progress of the project.
2. A dedicated project manager should be nominated for the complete project lifecycle: Right at the Project Initiation phase, a dedicated project manager needs to be assigned for the project. The selection of project manager should be very carefully done, keeping in mind that not only he should be expert in managing a project but he should have ample business knowledge also related to the project he is being assigned to manage.
3. Role of project manager and team has to be well defined at the start of a project: The roles and responsibilities are important to be defined well in advance to clear any ambiguities and to smoothen the progress path.
4. The project manager will act as a consultant to the customer regarding project plan and its adherence: It is the sole responsibility of customer project manager (and in turn their top management) regarding availability of customer project manager and key users in various stages of the project as agreed upon. Project Manager and the supplying organization have to act as a consultant. The responsibility to gear up the progress falls on the customer team. Vendor team can help them in support and educate them on how to achieve it.
5. The management has to ensure that the project manager and the team chosen for the customization/ development have to have enough business knowledge (of their respective domain) apart from technical skills: As mentioned above regarding the project manager, the same holds truth for developers, and testers too. Without reasonable business knowledge, even the expert developers and testers will not able to do the full justification to the product being built/ developed.
6. Project Manager has to ensure during the project lifecycle that the person who is signing off the requirements, UAT, and other stages from customer end is authorized person from customer management to do so: Many a times it happens that in a very busy scenario or with some other top priorities in hand, the customer management instead of releasing appropriate person for the relevant job, ask some junior person to do so which creates lot of issues.
20 points for organizational self evaluation to check where it stands in Software Project Management
2. Are you using some metrics to check if this is the right methodology?
3. What is the degree of improvement required in your current methodology to meet your customer expectations?
4. What are your organization’s primary and secondary goals?
5. Do you agree that there is always a scope for continuous improvement in everything we do – be it process, method or skills?
6. Do you agree that a product developed without any pre-defined procedure has varying chances of success?
7. Do you have a culture of performing development and testing as separate activities?
8. Do you assure a bug-free product at the time of its release?
9. Do you see all your processes integrated going hand in hand?
10. Do you get your payments from customer in time?
11. Do you have a process to capture customer feedback and request?
12. Do you have an innovation process in place?
13. Do you have a post implementation review in place?
14. Are your project managers and their teams aware of their roles and responsibilities – on-site and off-site?
15. Do you have project overruns often?
16. Do you have a risk analysis and planning process in place?
17. Are your employees delighted in doing whatever they are asked for?
18. Do you have empowerment process in place?
19. Are you certain about success in your projects or is it by chance/ by luck?
20. Do you have a repository of code, test cases etc. for re-use?
Why software testing effort estimation is important after functional specifications finalization phase?
If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.
To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.
1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.
10. Document with complete and clear requirements is as important as oxygen in the air: Requirements based testing is purely based on the requirements specified by the customer or software sponsor during the business requirements study phase. Documentation of all requirements (user level and management level) at micro level is very (Very) crucial. Missing out any requirements or unclear requirements can call for a big problem at the implementation and project close-out stages. Getting the sign-off to freeze all requirements is equally important.
9. Requirement freezing does not mean “No Change”: You can’t close your doors for a change in requirements after initial business study phase. The business and business rules keep changing thereby meaning that the CHANGE in REQUIREMENTS can happen at any stage after requirement freezing till the project close-out. The impact of change on time and cost is a different subject altogether.
8. Start building test cases” along with the development: The moment after requirement freezing as discussed in the first point above, the project manager’s first job is to do the resource management, requirements break down in tasks and task allocation for development. At the same time, the testing team has to start understanding the requirements and build their extensive test cases based on the requirements.
7. Business Knowledge is as important as the testing knowledge: The rule of 50:50 is applicable for both – the developers as well as testers. It has to be 50% technical knowledge and rest business knowledge for developers. Similarly the testers should have the same ratio between the business knowledge and the testing knowledge to write down the sensible test cases.
6. Confirm complete coverage of requirements in your test cases: Ensure that the requirements are completely and exactly covered as per the business need built in the software (or being built parallel). Incomplete coverage of requirements in building test cases will again result into a disaster for the project and product.
5. Change your test cases alongwith the Change in Requirements: For the purpose of requirements based testing, you have to keep modifying the test cases after understanding the exact changes required (documented and signed-off). Don’t forget to vet for the change coverage in your test cases re-built or modified as per the need.
4. Build a repository of your test cases: Building a repository will always help in saving of time writing the test cases afresh in case of similar (or same) requirements scenarios. So keep building your repository with clear documentation of the coverage a set of test cases is meant for.
3. Start testing as soon as one unit is ready: Don’t wait for the product development to complete. Start your testing as soon as the smallest unit is done, so at least the unit testing is over alongside the development (and most part of integration testing too as the units are increasing during development).
2. Re-test to confirm: Re-testing of your test cases with the business requirements is as important as the re-verification of test cases built.
1. Measure the benefits of Requirement based testing over the post development testing: Don’t forget to build a small metrics to measure the benefits drawn out of your requirements based testing in comparison to the complete testing being started post development. This analysis will definitely reflect great results in terms of time, efforts and money.
The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):
2. Standards and Methodology
4. Stakeholders rights
6. Pro-active approach to avoid post-mortem
7. Universal approach for similar projects
8. Timely completion, sign-offs and payments
9. Customer satisfaction and delight
10. Customer requirements and both end clarity on objectives of the product
11. Team building
12. Roles, responsibilities and accountability
13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall
14. First time right approach
15. Quality right from start – ongoing – every step
16. Increase in revenue
17. Avoid revenue loss
18. Reduce costs
19. Avoid cost increases
20. Improved service
Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.
In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control
Recently a US passenger Airbus had a serious problem just after it took off from the Airport. The plane suddenly lost power in both engines, and pilot Chesley Sullenberger judged that it would be too difficult either to return to the airport of departure or to land at a nearby airport. Instead, he decided to land on the Hudson River, which in the middle of winter was frozen over. With hardly any time to think, Sullenberger drew on all his professional experience and self-confidence and made a snap decision. His decision saved the lives of all 155 people aboard the plane. Sullenberger was the last to leave the plane, and did so only after making sure that everyone else had been rescued. He did everything he had to do right through to the end.
Some learning points can be drawn out for the project manager who is the pilot of a project. The problems and failures can be part of any project, but the project is not dead till the Project Manager raises his/her hands against those problems and failures. A good project manager will never give up till the end and apply all his inherent skills to overcome those problems and failures to make that project a success. The learning points from this incidence can be summarized as below:
Don’t lose hope
Use your professional experience to overcome any crisis
Keep your self-confidence up always
Be ‘quick’ in taking ‘right’ decisions
Take responsibility to rescue all on board – your teams, your organization, your management, your customer and your product
Let others cheer individually on their successes/targets achieved but your cheer moment is only after the successful end of a project
Dear Product Manager don’t cheat your customer by bypassing final ‘testing’ of the product before launch
When work pressures are too high, deadlines are on head, we tend to bypass our own standards, procedures and policies. A product manager if affords to skip testing for that purpose, that means he is committing a crime which is quite serious offense. Any management supporting this idea becomes part of the crime. Testing on ‘wish’ of a person (the product manager), depending on time availability or delay in development clearly states there are no plans in reality. If development of the product is delayed, the implementation can be delayed, whatever be the pressure from customer. If customer is befooled by declaring that the product is ready to launch (which has in actual not been tested properly, and customer is unaware of this), that means the customer is being cheated.
The whole scenario calls for a delay or failure, but who cares – there is no discipline being followed and the confidence is – “we will handle any situation”. Had the product launch been delayed by clearly stating to the customer (or to the top management, if pressure if from there) that the testing and fixing of bugs will take some more days, the customer (or top management) would have always welcomed the decision and would surely have understood your compassion (and passion) towards product, organization and the customer. Definitely it is a call for troubles during launch and implementation stage if the ‘testing’ has been bypassed.
If this is so, we still are the same as we were, have learnt nothing from the past and are betting for failure in success. That also means that QA is being displayed as a ‘showpiece’ to customer or to top management.
Endnote – if you have an opinion that ‘testing’ or QC of the product is a useless activity, if you believe most of the bugs reported by the testers are useless, you are as right as your highest level commitment towards the product, development, yourself, your customer and your organization.
During one of my initial management trainings (years back) I learnt the different between hard worker and smart worker. This example I could never forget even after so many years. Example of a hard worker is a person who comes to office in the morning, puts off his shirt, start pushing a wall, and keeps pushing it throughout the day, keeps sweating, keeps management happy that he is working very hard, and goes off tired and weird at the end of the day with no end results. The wall is there as it is where it was in the morning.
The example of a smart worker is who comes to office, smartly dressed, hardly do any work himself, but still the results keep pouring in, the management remains happy with him.
In harsh words – there is a difference between a donkey and a horse.
Every project manager has a project charter, plan and schedule. Every project starts, but very few end in time with complete satisfaction of customer, management and project team members. Why so? Efforts are put in, in all the scenarios, but all do efforts do not fetch good results. Where lies the difference, is an important point to introspect. In most cases, even if the project fails, the project manager do not let the axe fall on him by proving n no. of reasons mostly situational and saves his skin. But at what cost and who is the loser? The management and the customer are the biggest losers in any project failure.
A project manager has to be ‘smart’ all the time to manage the project and for its successful timely completion. Major issue during a project is to be pro-active and smell the issue before it gets out of control. Second major issue is managing everything on your own, and hiding some bottlenecks from the management or customer. Infact by raising your voice and informing them about your problem related to the project will get you the solution faster and better. Taking the problem where you alone are not able to find a solution will enhance your image in their eyes. Similarly tracking your team is equally prime. Managing project is simple if your thoughts are not complex.
Dear Project Manager – your “faith” in 5 pillars of project can get you miraculous success in any Project
I remember a small inspirational story read somewhere recently. A small girl took all the money she had in her piggy bank and went to a nearby drug store. The drug store owner was busy on a phone, and the girl was waiting for him to get free at the earliest. As she got desperate she interrupted the owner – “excuse me – I want to buy miracle, how much it costs?”. The owner kept on talking over the phone with giving an ear to her. She repeated the same again, this time in a raised tone. Owner told her as he is busy talking to his brother staying in a far country after a long time. The little girl literally had tears, helpless as if she wanted something urgently. Another man was standing inside the shop. He got curious by what the girl had asked for. He asked the girl – “what do you want?”. She said I want miracle, and I have money for it. “But what do you need it for” – the man asked her. “My brother is very seriously ill, and my mother says only a miracle can save her” – she replied. The man was the most senior neuro-surgeon of the country. He accompanied the girl by saying – ok, I have the miracle, let us go to your house to see your brother. The boy was operated free of cost and got well. The total cost of operation was “FAITH” of the little girl and some dollars she had in her piggy.
Like the little girl, the project manager has to have this tool with him all the time to win over any situation and to gain success in any project. The 5 pillars of the project where a PM has to put his total faith into are:
5. Customer: The customer is the on whose money your organization, management, your teams, and you exist. Your faith in customer has to reflect in all your discussions, communications, deliveries and product. Chose your words very carefully when you are in front of your customer or even when you are having an off-hand communication through phone conversations, emails etc. Your actions speak louder than your words. So take care of your gestures and bod language too.
4. Management: Your management is banking on you for the building and delivery of the product. Don’t mingle facts with over-enthusiastic assumptions when you present the project report to your management or to your customer. Be realistic and conservative in presenting the facts and projections.
3. Team: Don’t divide your team into doers and non-doers, slow and fast runners, perfect and imperfect. Labels regarding the individuals once set in your mind will drastically and adversely affect the project. Trust them in the same volume as you want them to trust you.
2. Processes: Whatever processes and procedures you adopt for project management, follow them ethically, trust them and they will deliver you the best.
1. Self: This is the prime factor. If you don’t have this, if you don’t trust yourself, you will not be able to adhere to the 4 points mentioned above. You can (deliver your best) only if you think you can.
Miracles do happen but only buying coin is TRUST.
A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.
Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.
Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.
So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.
Milestones have more visibility as compared to tasks.
It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.
Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.
Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.
Transparency about the project progress is as important as the authenticity to both – the management and the customer.
Integrity of task completed is another measure that you have to take into account for your project completion.