Post implementation support includes customer registering the problems related to the product and the product owner resolving it. There has to be an agreement or contract of service that defines the level of support.
Customer may report about a problem in various manners viz email, web portal, IVR, phone etc. giving too many windows to customer to register a problem, itself becomes a problem for the vendor. Vendor must ensure that any call coming via any media, must go to a central repository. If all calls from a customer are not registered in the database or central repository, the purpose of recording a call will not fetch out any useful results at a later stage.
Vendor will not be able to monitor the calls, keep track of open calls, or maintenance of a proper history of resolutions. At any later stage also if vendor decides to do some analysis, it won’t be possible if the repository contains partial number of calls.
Sometimes vendor wants or doesn’t want, pressure may come from customer end to produce analytical reports, failure of which may cause troubles in further renewal of contract or payments.
Product is understood, developed and implemented. Sign off has been taken, and post implementation report is submitted. All is well so far. What now?
Next leap of journey begins. The product usage, results expectations and problems encounter. Users get into the product on their own, start digging it deeper and deeper to understand it more and gradually get more confident. Problems encountered are being reported to the support contacts and issues are getting closed sooner or later.
But one point is skipped. There are many problems which are repeating every month. Customer reports and gets the solution but the level of confidence is lowering. Customer has started getting annoyed due to this repetition of problems.
Repetition of problems needs to be addressed. It is the most crucial factor and may become skeptical.
Someone needs to look into it and notice the deteriorating health of the product.
If the Project Manager doesn’t know the direction of the wind, he can’t be a good sailor. To drive a project a project manager need to set certain milestones. To make these milestones achievable on a regular basis (weekly, daily, hourly) he needs to break these milestones into tasks and sub tasks. These tasks are assigned to appropriate team members with the mutual consent on deadlines to finish the task.
The deadlines are closely self monitored by the task achievers (programmers, developers, testers,…) to maintain the rhythm and momentum.
At any moment if a task is getting delayed to finish, an alarm is required to be raised so that all members get alert and focused to find out the delaying factors. These factors are then analyzed and overcome with the team effort.
The direction of the wind keeps changing. So should be the priorities and planning of the project manager.
Project performance is the resultant of performance of each and every component of the project. Components of the project means – various team members. These team members are assigned various tasks and sub tasks of the project. The result of these assignments collectively draws out the overall project performance at any moment.
If any of the project tasks is not finished as per plan, the delay will effect the finishing of forthcoming tasks. Project manager has to be a good analyzer, critic and observer to identify the performers delaying the project from its plan. Once identified, the analysis can give the reasons of the delays.
If these reasons are timely identified and addressed to, the delay can be shortened and the performance of the project can be streamlined.
An eagle’s eye is required to identify the performance bottlenecks proactively to act upon to achieve the tasks as per plan.
Every project has a number of milestones. The achievement of each milestone establishes a landmark covered in the project thereby reducing the distance to the final destination. The milestone is divided into a number of tasks which are further divided into sub-tasks. A set of tasks is assigned to a team and the sub tasks associated are distributed among the team members.
Each sub task has two important coordinates. One – the owner who is supposed to perform this sub task and the time required to finish it. Completion of the sub task before the stipulated time is termed as ‘Successful’. Completion of any task/ sub task/ milestone beyond planned time marks it as ‘Delayed’. Non completion of any task marks it as ‘Failed’.
Result of a task or sub task delivers many important hints. It sets the further direction towards other tasks/ sub tasks or milestones. If result is ‘success’ the direction sets towards further tasks. If the result is ‘delayed’, it impacts on other tasks. If the result is ‘failed’ all focus is set on the current task to make it success.
This multidirectional focus on a single task has a propagating impact on further tasks.
1. At times development, requirement freezing gets done side by side and that too at customer location. In that case the product undergoes a lot of changes based on customer feedback on daily basis and finally product gets ready as per development team and customer.
After that it comes to QA for testing.
Is that right?
And how QA’s role differs here as compared to the scenario where customer requirements are freezed, product is developed, QA is done and then it goes for beta release, and final implementation
2. What if requirements are not documented properly and development team is dependant on what is told to them by the person who went to customer site for business study. But this guy has no document signed by customer; in that case if he has understood the business processes wrongly, it gets coded wrongly.
On what basis QA conducts the testing in this case?
No project can be started without estimations. The estimations are to be done about the resources, manpower, team compositions, budgets, releases, development and so on. Estimating software is not an easy task. Production estimations are simpler as compared to service delivery estimations.
More machinery involvement eases your estimations. On the other hand the more human involvement increases your estimation pains. There are more chances of your estimations going haywired when you are totally dependant on man than a machine for delivery to a customer. Machine breakdown can be handled in a more technical and professional manner. But to manage people you need extra skills to manage all kinds of turbulence.
Software project estimation can not be done just once in the beginning and then every thing moves accordingly. It has to be monitored, assessed and re-estimations need to be done from time to time.
Estimation is an art and skill which gets polished with experience and time.
Measurement is important to manage. We manage money in our bank by keeping a track of the credits and debits. The performance and versatility of project management goes in the same manner. There are plans, estimations, targets, budgets, resource crunch and so on in any project.
The ability to achieve the best results crossing all these hurdles is what makes a project manager and project teams successful. One of the most important purposes of measurement is to improve. Improvement is important in all aspects and in all directions. If customer requirements, software development, management goals and customer expectations all gel well and take care of each other, it will result into a win-win situation for all.
Measurement is also termed as Metrics. Project Measurement that way is known as Project Metrics. IT Metrics is the term used to measuring various processes and activities of IT.
Metrics methodology is quite important. Metrics helps in tracking project. It also helps in keeping all informed about the project current state along with increasing the productivity of the different teams working on the project.
Project management is an active stream worldwide. New methodologies and technologies are being produced and introduced from various corners of the world. Some organizations are quite active in optimization of software project management. By optimization we understand the productivity and quality increase. Some of the technologies and methodologies are not as effective as others.
There are certain standard analytical approaches used to evaluate and measure the effectiveness of such technologies or methodologies. Software maintenance is a long phase post project completion that manages the customer and product delivered. The shortfalls in the product delivered may cause a painful experience for the maintenance or the support team.
Every project needs to be managed. Different businesses acquire different methodologies and tools to do it. The level of maturity of the organization decides on the level of methodology or tools in use. It may happen vice versa too. Highly matured tools and world class methodologies may help gain high maturity to the organization.
Business requirements and customer specifications when are met perfectly above 90% in the software built; such software has least chances of failing due to quality or customer acceptance. Definitely the time schedules are always important but such products where business requirements and customer specifications are understood well and built perfectly in the software will require least changes at later stages.
The objectivity of project management is fruitful and worthy in such cases. Success is mostly ensured if such factors are well kept in mind right from the first stage of the project.
It is not easy to capture the complete, accurate and clear customer requirements due to many factors. Some of the prominent factors could be:
Wrong users chosen for prescribing business requirements
Wrong scope defined for Business Analyst
Incapable Business Analyst
No Top management involvement from either/ both sides
Language barrier especially in case of overseas project
These are few of the major reasons but not all. In real scenario sometimes all requirements do not emerge in one go at the initial stage. They evolve along with the discussions, meetings and brainstorming.
In such cases the project goes in iterations with the building of prototype of the ‘so-far’ understood product and its demonstration to the customer for two reasons –
2- to move ahead in terms of requirements and building of product.
If customer requirements and business process are not the top priority during the software development; then the software built will have a very short future and less commercial value. This is because, if the software can not cater to manage or enhance any business, its demand will be very low in the market.
The low demand impacts on the commercial value of the product mostly. Even if a very low priced product is in high demand in the market due to its high business value; an increase in its commercial value will not affect its growing sales. As long the software acts as a strong business tool, its demand keeps increasing.
Rather if we see some quite low value products do well in business profits due to very high volume sales. One way of deriving at the product value is to calculate the number of man months spent on the development of the product. This costing model works where the product is focused on a single customer. Development of the product means the complete development cycle including testing, rework etc.
But sometimes this cost is so high that product can not be tagged with this price. Then the costing model is worked on division of total cost of the product incurred to the estimated number of customers per year. The total cost is planned to be recovered in a three years or five years model.
The purpose of a business seeking software application to cater to a business process or a group of business processes is to optimize the business. The requirements emerge through the key process owners of the business. The requirements analysis and gathering phase is the most crucial of all stages of a software project.
Any software organization which does not understand the gravity of capturing of right set of business requirements in the first go, can never deliver the right product to its customer. If software is built for the sake of building some features and functionalities without understanding the real business requirements; the software can be a good showcase for demonstration purposes but can not be a useful tool for any business.
The business requirements broadly are spelled out by the top management along with the identification of core business process owners in the organization to further explain the requirements upto the micro level. These core business process owners need not necessarily be the top management.
Infact mostly they are not. These are the people who are there with the organization for some considerable amount of time. This is not the only reason for them to qualify to become core business process owner. They must be in the main driver seat. Every department or business process comprises of some people who drive the business process.
If requirements for any business application are not taken seriously, it not only hampers the targets and budgets but also create a deformed product.
A study shows that incomplete, improper or imperfect requirements collection during business and requirement study leads to 70% defects in the final product. The shortfalls in the software product delivered to customer affect its business process not only initially but for long. As long as, till the shortfalls are identified and fixed.
Each shortfall accounts for a risk. Each risk calls for mitigation.
Usually customers either are not able to identify the shortfalls completely during the implementation phase; or the incomplete identification does not lead to the proper fixing plan. Some fixes may require a major overhaul of the product. Gradually, customer compromises with the shortcomings of the software and starts using it as it is. Sometimes such a compromise may even lead to a change in the business scenario/ process in practice, which no customer would like to.
Incomplete requirements have a long lasting impact on the product to be developed and leads to a big scope of loopholes in the product segment as and when it gets developed. The entire teams get into wrong loop without even realizing the wrong direction being taken by them. The quality team, for instance, may have done a wonderful job in testing the product by reporting complete range of bugs. But tragedy is that the testing is based on wrong base of requirements thereby putting a big question mark on the report submitted.
At a later stage when awakening happens regarding the requirements, it might be too late to revert back or a big chunk of the product may require complete overhauling. Sometimes it may require even scrapping of what has been developed and the entire team may have to build entirely a new product to cater to the later understood business needs. This will lead to complete product lifecycle stages of development, testing etc.
Around 50% of software projects either overshoot the timeline/ targets, cross the stipulated budget, or do not satisfy customer regarding the features and functionalities. The plan overshoot is definitely deciding factor for the budget overshoot. These delays not only affect budgets, schedules, organizational reputation etc. but also decrease the customer base and business.
Overshooting of timelines or planned targets is bound to happen to cause budgetary turmoil. The causes of delay in timeplan could be many. It may effect due to:
2. shortage of manpower,
3. lack of management control,
4. unclear customer requirements,
5. ambiguous or unreal plan,
6. change in team members,
7. project manager’s knowledge,
8. lack of technical expertise,
9. lack of functional expertise,
10. and so on…
Delays do happen even in most properly handled situations but the worst is the quick response to manage them and turn the soar situation into sweet.
As per study software development team on an average spends almost 40% of their time on rework. The rework requirements may arise by way of – development team revisiting their code and finding out some lacunae; Quality control test/ bug report; or requirements fine tuning at customer end during the implementation or UAT phase.
Requirement fine tuning and new requirements arising during the various stages of a project are two separate entities. It is very important to identify and keep track of both. Fine tuning may arise due to lack of understanding business requirements during requirements study phase. It may also arise due to the lack in giving a proper understanding by customer to the requirement analysts. The reason for this may be lack of involvement at customer end, wrong selection of key user or else.
New requirement arising during the development or implementation phase is again due to both the reasons mentioned above. The new requirements arising at the implementation phase are very dangerous and deadlier for both ends.
The earlier identification of new requirements or tuning requirements ask for less efforts as compared to these getting identified at a later stage.
Using best methodologies, procedures, tools and practices do matter. But what matter more is the human factor. It is the people who have to drive the project. As best people under perform in subdued conditions, similarly the best of the tools and methodologies will not be able to get you the optimum benefits out of them unless you have good team members, administration staff, team leaders, project manager, tester etc.; if not the best.
These are the people who are going to work according to the pre-set methodologies using the available tools to give you the best results. It is not either-or condition. It is ‘and’ condition that works here. All above have to be good. The people, the methodologies, and the tools. Definitely one thing more that will work as a booster, will be the management policies and strategies.
Methodologies once adopted are sustainable, tools once built or procured are also sustainable. It is the people who are volatile. Their sustenance is the most difficult part during the ongoing projects. Someone leaves the job, someone goes for a long unplanned leave, someone gets de-motivated, someone doesn’t like the way things are being handled. There are n no. of reasons for not doing a job and not delivering the best.
People who love their organization deliver their best. It is the passion that drives the people, passion with the organization, passion with the work. This drive derives the desired deliverables.
Software project may finally result into success or failure depending on certain factors. It doesn’t exactly depend only on the methodologies and tools adopted during the project lifecycle. It also depends on the human factor comprising of administration, team members, team leaders, project manager, management strategies and above all the culture of the organization.
The methodologies and tools on one hand do help us in tracking of project progress and assessment of project health at any moment during the project lifecycle. It depends on the quality of tools adopted and the standard of methodologies in use. The whole process of tracking and assessment via methodologies and tools may range from the simplest manual process using word documents as standards and excel as assessment tool.
The next level could be by using some simple project management tool like MS Project. If cost is a constraint initially to spend on tools and methologies – there are certain open source, free of cost project management tools available. Some of these tools are quite competitive with the cost based tools. The detail of such tools can be searched over the net or may be requested from the author.
An organization is driven by some set of rules. Few of these rules are so hidden in the process that they are not visible or known clearly. But those rules keep being followed inherently. Other rules are quite transparent, visible and known clearly.
The organization behavior, management style of working etc reflect these rules or are guided by these rules. The governance is so automatic and self driven in most of the cases that which rule is governing or deriving what decision is sometimes difficult to find out. The management and employees are thus so accustomed to this scenario that they forget to think about any change in the working style or find a solution to some problem in an innovative way.
There is no defined guideline or process in most of the organizations to identify or review these rules from time to time. This calls for the same rules, hidden or visible, be followed year over year without being challenged for a change. Though the requirements may have changed which may need these rules to be reviewed and changed, it keeps going on and on without any notice.
The management’s involvement in this scenario is quite important as the people down the line either are unaware or not authorized to ‘change’. It is the prime role of the management to review, assess, and identify the rotten eggs from the basket and put them in ‘to change for better’ bucket. Then a separate team can work upon the change required in those rules for the purpose of optimization or enhancement.
1. One big mistake that a project manager makes is that testers are not treated as major stakeholders in the project.
2. Development team has a misconception of treating tester as someone policing and pinpointing loopholes in developer’s area of expertise.
3. The test team is intentionally kept out of loop upto a certain stage of the project.
4. The knowledge transfer from development team to test team starts at a later stage and immediately they are told to start testing without providing them ample time either to absorb what they have understood about the customer business or to prepare test cases for complete coverage.
5. The bugs reported are not taken as seriously as they are reported – usually the bug closure priorities are set more on the basis of time required to fix a bug or the time left to release rather than the severity of the bug. Most of the project meetings are conducted without test team involved in it – and worst thing is that a lot about quality is discussed in such meetings.
A tester’s prime task after testing a product is to describe the bug. The development team while receiving a test report of a product from tester expects a detailed bug report. The report should be presented in such a way that is easily understood by developers. The point of confusion most of the time is a tester while reporting a bug, if know the best possible solution to be incorporated in the product. Should he report it as a part of his bug report or keep silent about it and let the developer explore the solution on his own.
There are two aspects to it. There is already a feeling in development team that whatever they produce goes to test team for finding bugs or any other inconsistency. This does not give a comfortable feeling to development team. On top of it if a tester tries suggesting a suitable solution for fixing a bug, the developer might get hurt.
This might give him a feeling that on one hand the tester is exploiting the code written by him to find out bugs. On the other the tester confidently suggesting a suitable technical solution to fix a bug to a developer, might give him a feeling that his knowledge is being challenged. This might be taken by the developer as a two way attack.
The tester has to be quite cautious in suggesting a solution for fixing a bug reported by him.
1. During all the project management phases, each process should be clearly having operational key indicator metrics to measure the health of the project at any stage.
2. Approvals, decisions, milestones, tasks, micro tasks should not become a hurdle for the project.
3. People driven project has less chances of growth as compared to a process driven project.
4. Pace, growth, acclamation, business and revenue can be achieved with the help of benchmarks, standards, methodology, procedures, reporting etc. on one hand and engagement, personal growth, commitment, employee delight etc. on other hand.
5. People are not bad – neither those who are part of management nor those working below. It is the process and procedure of management that makes the difference.
Peers: There is always a peer pressure, right from our school age. There are people who always try to make you feel inferior, or insignificant so as to increase their importance of for any other purpose. The same happens in corporate world too. There will be people at your level who will try to highlight your shortcomings or failures in front of the management just to hide theirs. A minute issue will be reflected as a bottleneck by them. They also do with the intention that you be always in defensive mode and they be always be in attacking mode. Management’s role is very important in such scenarios. How to cut such person’s intentions is your area to understand and act.
Project: Project is bread and butter for a project manager. He can not afford to delay or failure of a project. The project reputation directly reflects on the organization reputation and further business. It is also important for the sake of your own progress.
People: You will find all sorts of people in peers, subordinates, juniors, seniors. Some may like you, others may dislike you. Winning second lot is an important factor. Once you manage to win such people, it will always help you in managing any team.
Plan: Promises are made to break. Plans and commitments are made and presented not to be adhered to. This is not possible in Projects. A single failure in adherence to a plan’s task or commitment needs introspection. Remember the famous saying – “Never repeat a mistake”.
Priorities: Learn to prioritize your tasks. Out of hundred tasks in your hand you cannot focus on all at the same time. You need to prioritize your tasks and finish them as per priority set. Remember – “You cannot eat an elephant in one go”.
Prestige: Your Project prestige affects your own prestige in the organization. Honor your words and commitments given to anyone – be it team members, management, customer or peers.
Presence: You need to make others feel your presence in your project. You should not be ignored in any decisions related to your project. After all if it is you who owns the success or failure of the project, how can a single decision related to it can be taken by any one else without your consent.
Patience: Patience is very important. People around will try to exaggerate situations, excite you to react abruptly or make you give wrong commitments. Don’t react too hurriedly in any case. Understand the situation and act accordingly.
1. Key users are selected based on their organization engagement, knowledge about the business; and their own area expertise.
2. The selection criteria also depend on their openness and acceptance to adaptability, manageability, and their goodwill.
3. Key users play a major role in representing their organization in terms of defining business requirements to the business analyst thereby defining the scope of the software requirements.
4. Key users group play a vital role between their management and the product.
5. During the development phase key users can help development team to a large extent in checking and confirming if the requirements are getting built in the right manner.
6. The product specifications derived from business requirements when built are demonstrated to the respective key users for confirmation.
7. Key users have also to ensure the proper cross integration of the business requirements embedded into the product.
8. The Key users are responsible for a long term tie up with the product when handed over to their organization.
9. Key users are not only responsible to manage the product but also to keep educating the new recruitment connected to the product function.
10. For any change in the business requirements, it is the key users who are expected to get it built in the product.
You have many projects running in your organization. You have to compete with peers, competitors, time, money and yourself to manage these projects to finish in time. There are clashes in priorities among various project timelines. You have instances when you have to change your priorities depending on situation of various projects. These changes might be due to people involved in the project, customer, management, technicalities or functionalities. As your project is at stake and need to be finished in time, others also have the same needs. With the limitations of scope, people, knowledge and involvement; you have to cope up with all situations to strive and thrive.
At times a project manager has to reprioritize and reschedule. Reasons could be many or any. It may be the demand of the situation that a project manager is forced to change his strategy, plan or methodology. Only word of caution is that the more frequently it happens during a project; more hassles are created for him and the team. More so painful it becomes if no standard process is being followed in the organization to mange projects. Whatever may the situation be; the changes should be visible clearly to everyone across the teams involved in the project. Though it will be painful and challenging for the project manager to manage but it has to happen as it is very important to be on the same carpet.
Such intense situation help project manager and team members mature faster. The project manager gradually has to expertise in key tactics and deep insight to manage current project and forthcoming ones.
1. Customer Management: Usually the top management’s involvement is very important during any stage of a project.
2. But tragedy is that they contribute too less in the project.
3. They consider themselves as the busiest person on this earth and for this reason they direct others to invite them only when crucial decisions are to be taken during a project.
4. They keep themselves limited to only crucial decisions and are unaware during the project what is happening under the water.
5. Since they don’t carry the actual knowledge of the progress of the project, they go by the feedback from their down the line people engaged in the project.
6. In such a situation their decision may change the direction of a project in wrong direction as it is highly under the influence of someone else in the team.
7. The person influencing such a decision may himself be having less knowledge of the project or be having some strong biased outlook towards the implementation party.
8. Top management will keep themselves engaged in other critical issues being faced by the organization to escape from the ownership of the project.
9. Though it is the customer who is sponsoring a project and paying money for that, but their internal unity becomes a big issue at times thereby giving birth to politics.
10. Sometimes ego among the top management too create silos and conflicts thus effecting a good project and team with wrong results.
There are many stakeholders having different proportions of stake in a software project. Some stakeholders engage themselves during the complete lifecycle of project; others feel their presence is not crucial for every stage of the project. If any stakeholders feel themselves in the second category, they are not only doing injustice to the project but also to their role and responsibility. A stakeholder may not be required to produce results or give decisions at times during the project lifecycle but their engagement is unimportant is a misnomer.
The major stakeholders whose contribution is most important in a project affect the progress of a project to a very large extent. Some stakeholders merely assume their role to sign the reports and project stage sign off without knowing the real state of project. Others assume just to be meeting icons. Some keep finding excuses to skip project meetings. Some stakeholders will have ample time for anything else except project. Some stakeholders will be very judgmental in giving their opinion about the future of a project right at the time of its inception. If they are so correct about their predictions, probably they should consume their talent in being a little proactive and finding out ways of mitigating their predictions about something going wrong with the project.
Any project, small or big, is bound to have risks. Risks perceived can be managed well as an advanced risk management plan can be prepared with the ways to mitigate the risk. Risks that are not perceived during the risk management plan are bound to create chaos and unplanned handholding at the time of its occurrence which may not necessarily be the ultimate way of managing the risk.
Following steps can help you in identifying, managing and planning the risk mitigation:
2. Allocate right resources and efforts to manage the risk depending on the level of the risk.
3. Form right strategies
4. Higher the risk (severity) does not always mean spend large amount for mitigation. A combination of severity of risk and its chances of occurrence will formulate its mitigation procedure and plan.
5. All risks may not occur that are perceived. All mitigation plans will come to use. Some risks that were never thought of will definitely occur sometime or the other. An ad-hoc mitigation plan will be required in those situations.
6. Planning, Testing and performing is very important. Planning alone will not suffice the purpose. Performing without a proper planning or testing may end up in unwanted results.
7. Attack the system or process not the people. It is lack of system or poor process that causes risk management ending up in unpredictable results. People love to live in discipline provided it is for all and not person based.
Problems are the reasons for opportunities. If there were no problems there would have been no opportunities, not much challenges, not much jobs, not much talent hunts. Tell me a project which gets completed without any problems. Tell me a person who has had no problem in his life. Tell me a day when there was no sunset at the end of it, all dark; and a bright sunshine after some hours back bringing the life and spontaneity.
Well, philosophy apart, there are three type of project managers to deal with problems in their projects. Each one of them has a different approach to handle, manage and tackle the problem. Each one of them is able to bring back the normal situation to make it appear that there is no problem. But, by the way each one of them handle the problem, you can clearly tell whether the problem is suppressed, hidden or vanished. The three approaches are:
1. Suppressors: This type of project managers will have a unique approach of managing the problem by finding out the team members who have created the problem. They feel that by punishing the people behind the problem will resolve the issue. It does, indeed, but not for a long time. It reoccurs, because people are people. They are not process.
2. Hiders: This type of project managers will not focus on the problem or the team members who are problem creators. Rather they will make their target the people who highlight the problem. The purpose is to keep the wall neat and clean. What is happening behind the wall does not matter at all. So intention of such project managers is to keep the rosy picture in front of the management without giving them a hint of lava boiling underneath.
3. Vanishers: This category of project managers will neither target the person who creates the problem or the person who brings it to the table. They will find out the loophole in the process that allowed the team member(s) to create a problem and fill it forever; so that such problem never emerges again.
Vanishers are better than both suppressors and hiders.
If processes are intact, in place and perfect (rather near to perfect, as perfect is an imaginary, unrealistic state); any sort of people will have to follow the process. The Vanishers believe that process driven projects are bound to be more successful than people driven projects.
For any software product development, the product can be managed in two manners by either giving the development and deployment charge to an internal product development manager or by hiring a product development consultant to manage an in-house team of developers. The same applies to the development of any product.
A parallel approach is adopted lately by many organizations by having the both. That means there will be a product development consultant and a development and delivery manager both working on the same product.
Why would that happen?
5. A consultant will never own the product or be responsible for the timely delivery. A product manager will have to do the both.
4. A consultant can be a front end for the customer featuring the highlights of the product or understanding their requirements for mapping and finding out the gap. The development manager can keep concentrating on product features and committed deliverables.
3. A consultant will be acting somewhat as a bigger umbrella over the smaller umbrella called product manager thereby giving double protection to the product and a shield to the product manager.
2. A product manager will focus on both – making the product feature rich/ stable and delivering on committed date whereas consultant will focus more on customer requirements enablement in the product and getting it done from the product manager.
1. The overall control of the development team will lie on the product manager. The responsibility of providing an extra edge of technology or feature will also lie on the consultant.
A Project is nothing but a collection of tasks, milestones and activities. These are managed with the help of some standard methodology, process and procedure. In every stage of project we are supposed to perform some tasks, achieve certain milestones by the way of performing activities. The tasks for distribution purposes are broken down in sub tasks and sub-sub tasks (and further on…) to manage and monitor them in right manner. A set of tasks will make you achieve something considerable that can be termed as milestone.
The five stages of Done can be:
5. Done: This is the best stage for any task during any project phase. Satisfaction level and tempo of the teams concerned would be at the highest level.
4. Reasonably done: This is quite satisfactory though lesser than the above stage. This stage still carries a high level of the probability of it reaching the above stage unless it is stuck at some point where a solution is not feasible.
3. Partially done: This is No-win, No-lose stage. Team would not be happy at this stage but still would be having an urge to speed up the process to bring it to Done stage.
2. Minimally done: This will be an indicative of something serious happening in the team. The cause could be either lack of right people, right technology or right direction. The chances of death will be higher than life unless some miracle happens.
1. Not done: This is a dead situation already. An immediate introspection will be required to do a deep analysis to arrive at a conclusion that whether to try it once more or call it off.
Mind it that any task, milestone has no meaning unless it is bound with a timeline. The above situations have a meaning only when a task is associated with a timeplan.
You might be a project manager, senior management, customer management, customer project manager, quality manager, development manager, business manager. That makes you an active and responsible stakeholder in the project. Your role is not just to release or collect that piece of information at regular intervals; and dump it. If you do that, you will be the happiest person on this earth only till you are not caught doing it and are not dethroned. Your job and responsible position in the organization also will not allow you to just sit over it and focus on some other activities.
A running project is the prime objective of the organization and nothing can take priority over it. The main focal points about Project Information can be prescribed as:
5. Project information is very critical and important. Look from your perspective if it is completely satisfying your needs according to your job function. If it is claimed to be complete but insufficient for your respective role in the project – claim it, shout out, demand it.
4. Look at the project information as a critic. It might be ok for you for the time being but may be lacking some information that you will require at a later stage. Look at it at the point of valuable repository point of view.
3. Put yourself in every other stakeholder’s shoe and examine the information that is being generated and delivered. Someone in your peer’s section performing some other role might not able to examine it whereas based on your experience, learning, and knowledge – you might be able to help him to point out the missing piece.
2. Ensure that the information and its flow are following some standard methodology/ process. This is in respect to the frequency, timeliness and accuracy of the information.
1. Be an agent of your top management. Sometimes top management at both the ends might be involved in some other priority/ activity. Inform them appropriately about the green and red areas of the information to them and seek their guidance or give suggestion for some immediate actions if required in certain areas.
1. A project is associated with lot of information flow.
2. Be it any stage of the project, information is very important to understand if a particular project is progressing, accelerating, decelerating, not moving, illumined or merely under the influence of illusion.
3. If information flow is not appropriate or not feasible to access to relevant associate partners of the project (stakeholders), it may appear to be progressing in right direction but it might be assimilating lot of heat under the earth to burst a volcano at a later stage.
4. Sometimes that later stage could be very dangerous. It could be a stage where nothing is possible to recover from. It could be a stage where it is too late to go back and start the journey again. The starting point could be too far at that moment and invisible.
5. Project information is the right amount of information without any complexity to make everyone connected to project clear about the status of the project.
6. The information flow should be clearly defined (process of information flow).
7. It should also be available to right people in right amount at right time.
8. The information should tell about the milestones achieved, milestones missed (with age analysis).
9. Information should also tell about the micro level tasks (sub tasks and sub-sub tasks breakdown) targets and actual timelines.
10. Project Manager is straightaway responsible for not presenting the right information to right people in the project. Any wrongdoing in terms of information (wrong projections, inappropriate projections, false projections, incomplete projections etc.) should be the overall responsibility of Project Manager.
A reputation risk associated with a product is prone to cause a ‘bad’ reputation to the product. But reputation management does not limit itself only to mitigate reputation risks. Its other purpose is to increase the ‘good’ reputation factors. One way is to decrease the reputation risks which itself will increase the ‘good’ reputation. It is because if product keeps running smoothly without giving any trouble to the user or customer, the product is bound to have a ‘good’ reputation. A good reputation will definitely boost the morale of the organization that sells the product. And will also increase its reputation in the market, with a chance to increase its sales.
Both good and bad reputation can’t survive together for a product. It is the net resultant of the both, but not always. Sometimes a bad reputation factor overpowers many good reputation factors. A decrease in bad reputation or increase in the good reputation may or may not impact on organization’s increasing profits to a large extent, but a bad reputation spread in the market will definitely cause damage to the product further growth in terms of sales.
Both the aspects are equally important to focus upon.
As we know a risk to a product is connected to the risk to the management or organization using that product. The higher the damage involved with the risk the higher is the mitigation procedure required as a countermeasure. The reputation damage of the product not only affects the company using it but it affects highly to the company who has designed the product. There is one case when the high reputation risk occurrence will affect only the customer using that product and not the company who has produced that product – and that is the case when product is perfectly designed ok but has been used wrongly (or misused) by the end users of the customer organization.
The reputation risks causing damage to the reputation of the customer can be classified in following categories:
1. Non-significant Damage – Non signification or very minute risks will not cause any impact to the usage of product neither to the reputation of the product of customer. But when these non-significant risks start occurring in a higher volume the irritation to the user turns to a significant size.
2. Minor Damage – These types of risks cause minor reputation damage to the product. These could be divided in two categories. Either some non significant risks start occurring in a high volume or some significant risks start happening.
3. Moderate Damage – These risks are better to be identified in advance and must be handled accordingly. The moderate risk in the product will be prone to cause moderate amount of damage to the company using the product.
4. Severe Damage – These category of risks if identified already in advance and have not been mitigated, are like mini bombs existing in the product. The product owner releasing the product with such risks or the organization using the product knowing it has such risks are not doing the right thing. Only case where such risks existing in the product but not causing any damage is if they do not occur at all. Or if their chances of occurrence are too small, then the chances of damage also become negligible. But that is rare since the risk lying in this category has significant amount of occurrence.
5. Deadly Damage – Something occurring and causing such a high impact to the organization that its survival or existence becomes an issue.
Any risk that has been perceived already becomes the part of risk management document where its mitigation plan is already must be existing.
There is no harm in owning the product (on behalf of the customer) by the project manager during the development phase, but keep some key points in mind while doing it:
1. Ensure the business requirement documents are well in place and are quite exhaustive in nature to pin down the minutest of the business process that is to be built in the product
2. The availability of business analyst to answer a query related to the customer business as there are chances to skip documenting (unknowingly) something related to business which is clear in the business analyst’s mind but has not been documented clearly.
3. Be a ‘proxy customer’ in terms of clarity of business and processes so that you are able to guide your teams in the right directions.
4. Keep customer involved in the queries resolved and solutions proposed for the product as there should not be a gap between what you think as the right solution to a query and the actual solution what customer would have proposed. This is applicable for all business process and requirements issues.
Product development requires day to day interactions and query solving of the development team related to the product. The customer presence is not extensive and hence most of the product related queries have to be resolved by the project manager.
The business analyst becomes the handiest useful key to help project manager in resolving these product related queries. The business analyst is the only person who so far has interacted with the customer management and the end users to understand their expectations and requirements. That is why input of business analyst in such queries will be much more accurate than anyone else in the team. Infact sometimes even the customer will tell you to decide on your own if a nitty-gritty query is shot upon them to build a particular functionality or process in the product.
As long as the product is not ready to launch it is not a problem if the customer decided not a “own” it in real sense. This happens exactly. The customer has a mindset that he is “helping you” in building the product rather than taking the ownership right from the beginning of the project and deciding upon the direction of the project.
It is not difficult to answer who is the product owner. Obviously the answer is – “customer” who is paying for the product. Ownership always consists of two aspects, in all circumstances, everywhere in the world. The two aspects are “joys” and the “pains”. I buy something from the market – say plasma TV or a new mobile handset. I keep enjoying the comfort it brings with it and don’t mind even if I don’t share the “joys” with anyone else. But the moment it gives me a trouble or “pain”, I would like to involve the dealer, the product company representative and so on to share my pain or get me relieved of it at the earliest. I even won’t mind it sharing with my friends or family members to discuss the trouble it is giving to me and asking for a suggestion from them. Though these could be the persons not related to the product directly (or indirectly) or were not a least involved in the decision of buying this product.
So that is the basic philosophy of life. The more reluctant we become in sharing “joys” of life, the more it gets turned into “pain” to force us to share. As the mindset is – the moment we start experiencing “pain”, we seek its solution, thus involving the people most suitable for giving us a solution.
Human tendency of giving the “credit” of “joy” is mostly to himself; and assigning the “blame” of “pain” to someone else.
The same if we summarize in terms of a project, customer, and product – the customer will prefer to say least amount of words if the product is trouble-free but will speak more than his “heart” out in case of a small trouble the product starts giving.
1. Vision and Leadership: As a project manager never provide any technology vision and leadership in the development and implementation to your teams engaged in your project.
2. Planning: No planning must be done to build your customer’s operations in the application you are building. Thus this way you will not be required to provide any support at a later stage (since the project will never get over!). In worst case if you are forced to plan, plan for a most ineffective and costliest solution.
3. Strategy: Build a strategy to enhance all sorts of problems in the development, evaluation and coordination during your project.
4. Communication: Communication is your worst enemy. Build and maintain least communication between your teams, management, customer and other stakeholders involved in the project within and outside the organization.
5. Productive System: If you build a productive system, it will definitely stop the growth of end users. Let you be humane enough to not to stop them lose their productivity in any manner by giving them an effective system. Guide your development team to build simplest of the business requirements in most complex manner in the application.
6. Training: As a project manager do not plan any training for the product to the customer management or the end users. Even if you plan some training, you will not be able to conduct because you are not aware of the system you have built for your customer.
1. Project Definition: Either don’t define your project or define it in most ambiguous manner so that even if you read it again, you are not able to make anything out of it. Don’t define Project Charter comprising of project vision, project objective, project scope and project deliverables. This way you will never come to know what is to be achieved. So How to achieve and when to achieve will never bother you except that your project risk will shoot up manifold. And that is what we intend to do here.
2. Project Plan: Once your project definition is prepared in most ambiguous manner, start preparing your project plan in such a manner that it never sees the light of the day.
3. Project Team: Comprise your project team with lousiest people in the organization and give them liberty to do whatever they want to do. Don’t bother if they don’t understand what this project is about since you even don’t know this. Moreover if they come to know what this project is about, your task will increase. You will have to assign tasks to them and in turn your accountability will increase thereby decreasing the risk.
4. Project Risk Management: Do no risk identification, assessment, or risk mitigation plan even if you are able not to follow above steps.
5. Reward Scheme: Announce a reward scheme in your organization that whosoever will create risk for the project will be rewarded accordingly depending on the level of risk created. Motivate your employees, team members to contribute bigger and bigger risks to the project.
Though by following these steps you deserve the Highest Risk Creator Award but don’t be so selfish. Let it go to someone else. Trying is no harm, maybe someone else in the team is more talented than you.
1. Overcome constraints
2. Increase quality of service
3. Drive your team to perform better and become more productive
4. Keep yourself and your teams Happy
5. Have a stable and consistently improving process mechanism in place
6. Transform your teams to High Performing Teams
7. Keep your benefits higher than cost
8. Set your goals clearly
9. Drive yourself and make it mandatory for everyone in the team, your business will be driven automatically
10. Have useful self assessment tools in the organization to be used by everyone
11. Maintain bold leadership
12. optimize for Excellence, not success
13. Convert your process bottlenecks to process accelerators
14. Stand up to Threats
15. Have employee performance management system
16. Have a clear visibility on the work of the team
17. Maintain a delivery Cadence
18. Optimize software quality procedures
19. Maintain service and support driven by SLAs
20. Have a good communication system in place
21. Base your development on project objectives driven through customer requirements
22. Address all business situations
Reputation and reputation risk both are estimated during the project and the way it progresses while crossing its milestones. The customer is the last milestone in any project and it is the external agency like customer or the market from where the reputation or reputation risk is established about a product. Reputation and reputation risk are inversely proportional to each other. The Reputation on one hand brings in more business and orders. The higher reputation risk brings in a threat of lowering in business or product sale.
No organization or product owner wishes for a higher reputation risk. Though every product is associated with some percentage of reputation risk it will be foolish for a product owner or project manager if the risk assessment is not done well in advance and the appropriate steps are not taken in advance to mitigate the risk.
Six major contributors to the software project are:
1. Customer – end users, customer management
2. Product requirements – not well told, not well understood, not well documented, not well translated into the product
3. Project Team – documentation, development, testing, implementation, training
4. Development Process – how well the product has been understood and developed
5. Product Testing – it is not the tester but the testing procedure that matters more
6. Implementation Team – sign offs, training, meetings
Project Management is an Art and Science both. An artistic touch makes it beautiful. A scientific approach makes it successful. Both are essential in case of a software project. Hoshin Kanri is a Japanese term. In Japanese, hoshin means compass or moving in the right direction and kanri means management or control. The combination would mean either “moving in right direction to have a better control” or “controlling it in a masterly way to move in the right direction. This is a great tool for any management to enhance their project management or urge for excellence so as to move towards better optimization and least defects in their processes.
A well defined process and its adherence make it possible to achieve higher standards in process optimization. Many organizations have no defined processes in place. Others have well defined processes but no adherence or a wide gap in what is defined and what is being followed. The organizations are capable to sustain and enhance their growth and success via doing the both – defining best practices in their project processes and adhering to those practices so that there is least gap between the two.
An organization would definitely require adopting “Hoshin Kanri” if they are facing following issues in their project management:
1. If there is no planning process in place or if there is a process defined but there is no monitoring on a regular basis of what is defined and what is being followed.
2. If the processes are age old with no reviews and improvements analysis.
3. If the processes are well defined and lying in a closet and people who are the project owners are not aware of those processes.
4. If actions performed in projects differ to what is defined in the relevant process.
5. If processes are discouraging and demotivating in nature.
6. If lot of improvement projects are running in the organization with no or little improvement apparently visible.
7. If people are held responsible for failures rather than focusing on improvement of process.
8. If results of strategic objectives differ from actual work in place.
9. If opinions play major role in decision making than the facts trying to lead to different cause to be taken care of.
10. If Customer is not HAPPY.
2) Success is a combination of two main ingredients: Decision and Choice. Choice mainly comes from the top management, Decision from all levels during the different phases of a project. Any action on the project is a resultant of a decision taken by anyone in the team. The low level decisions are to be controlled by senior levels. The hidden or uncontrolled decisions may fluctuate your project’s SUCCESS between the two intrinsic limits – DISASTERS and HIGH ACCOMPLISHMENTS.
3) Opportunities do not knock twice at your door. You have to be intuitive and bold enough to recognize and grab the right opportunities.
4) Don’t underestimate you or your teams, neither the capabilities. Reach to your highest potential to fulfill your goals. Keep reminding yourself and your teams – ‘you can do it’
5) Define your goals clearly. Clarity in you will show right path to others too.
6) Every act is associated with a risk. You must be able to proactively identify the risk, perform risk assessment, risk analysis and find out ways to mitigate the risks.
7) Dream when you are asleep, achieve them when awake.
As discussed in the previous article “What is Reputation Risk in regard to a Software Product?” the situation can arise in case of any product or any company. There is no point in getting bogged down if after all sincere efforts the product has failed to be successful at customer place. Better option is to find out the reasons behind its failure or rather put all your efforts to find out what is missing in the product that has not been able to convince the end user and their management. Instead of losing heart and withdrawing the product, focus on those points, act upon them and reproduce the product to the management and the users.
The best way to do this is to quantify the reputation risk. The amazing reasons will emerge out once you start quantifying it. Worst scenario could be that there is nothing wrong with the product but still user’s acceptance level is quite low. Probably the product has been launched or introduced in a wrong way. Probably it has not been introduced to the users well. Probably its key features have not been highlighted the way they should have been.
Reputation risk of the product is a very critical factor related to a product that a company delivers to its customer(s). The reputation risk of a product is directly related to the rate of acceptance of a product by its end users and is indirectly related to the volume of benefit it delivers to the management of that organization.
Let use start with the customer requirements based on which a company decided to develop a software product. The software is produced after following all internal procedures of development, testing etc. and is declared as ‘ready to launch’. It reaches to the customer along with the implementation team. The implementation team educates the end users about the product and its usage. The end user starts using it but somehow feel uncomfortable in what they perceived and what it delivers.
If end user is not comfortable about the product functioning and its usage they will definitely not be able to deliver the desired results to the management of their organization.
The lack of interest by end user due to whatsoever reasons will cause a bad name to the product as it is not going to deliver the desired results in the organization. Assuming that the product has been developed with utmost care but still if it could not convince the users, it is a bad luck for the product and the company that has developed it.
This is how the reputation of a product is built which in turn largely affects the company who has developed that product.
There is no end to learning. Still water becomes contaminated and harmful for use. Continuous flowing water keeps it fresh and pure. Similarly if your developers and testers or for that sake anybody in the organization keeps performing the same functions without any improvement or value addition, it is like no update and no upgrade.
Any organization must have a continuous learning program for their technical teams. Rather irrespective of the stream a candidate belongs to, all must have a continuous learning program. Organizations that do not focus on this area, invite more employee turnover and less dedicated employees. There are many benefits beyond stated here but main benefits of having continuous learning program for project teams would be:
1. Performance: The performance of your project team members will increase manifold. Their efficiency will be better.
2. Recognition: Team members will be willingly staying for a longer period in the organization. So if their performance keeps improving and they stay in the organization for a longer number of years, definitely it is a boost for the organization.
3. Empowerment: Teams are self motivated, empowered and more organized.
4. Turnover: There will be tremendous decrease in employee turnover.
5. Flawless Speed of Delivery: The delivery in their respective areas will be flawless and spontaneous.
6. Role Models: Such employees with high performance, complete dedication, longer years of service and quick delivery will definitely set an example for others in the organization and hence will attract better employees to join the organization from outside. Internally also it will keep a healthy competition among the teams and team members.
7. Culture: This will lead to a strong learning culture within the organization. Continuous improvement will be a subset of this culture.
8. Brand Ambassador: Not only the employees working in the organization but even those who leave the organization and join somewhere else would be the brand ambassadors of the organization.
9. Consistency: The organization as a whole will be on a trend of consistently improving organization thereby optimizing its potential and achieving new heights. This way organization can aim for bigger goals to achieve.
10. Social Impact: With such a culture, the employees will not only be leaders within their own professional spheres but will excel in their personal arenas too thereby setting an example in the society.
Learning is a life long process with no bars.
Like a piece of software or hardware requires regular upgrades and updates to perform smoothly with the changes scenarios, a programmer or tester also needs the same. Or for that sake every human being on personal and professional front requires it. How it is done is important. In case of software or hardware the update or upgrade patch is released at regular intervals by their respective manufacturer or owner to keep it updated. How is it needs to be done in case of us – the human beings. Here comes the role of reading, exploring, training, brainstorming, discussion, interaction with peers and superiors etc. There is a big difference between the flowing water and still water. Movement is life. Improvement and enhancement are essential for growth at both fronts – personal as well as professional.
As we all know books are the best friends. Any read will give you some or the other learning. So it is important to keep reading latest books, articles, views relevant to your job. Join in some important newsletters, forums, sites that keep you abreast in your technology area. Reading blogs, subscribing to RSS is another thing that can be done easily to keep getting information flow. Training is important for all ages. There is no end to learning. There is always a scope of new learning, improvement and knowledge acquiring. Don’t wait for someone to sponsor for your training. Go ahead, find out the requirement for yourself and jump into a training session. Investment in training always gets you returns in manifold.
Project Management is vague if not adhered to a proper project management methodology. Project management methodology is useless if not in sync with a project. Quality Assurance is an integral part of project management methodology. The methodology need to be designed, managed, controlled, monitored, reviewed and fine tuned by Quality Assurance. Project teams need to follow project management methodology religiously.
Quality control goes haywired if not supported well by project teams. Project teams lose control over project at times. All these and many more factors need to bind project team, quality assurance team, quality control team tightly so that they all aim to a common goal of successful project completion.
Following are the major linking factors between project management, project team, project methodology, quality assurance and quality control:
1. Visibility of Open Projects: There need to be a bulletin board related to all open projects visible to all stakeholders that is updated regularly stating the progress status of each project.
2. Team Members: There might be n number of projects running and in pipeline. The team hierarchy, member names, responsibilities, jobs assigned and work status for each project should be visible to all concerned to keep them all in sync.
3. QA Compliance: Project Management Methodology compliance is part of Quality Assurance. It is quality assurance (QA) head’s responsibility to design the right methodology and ensure its adherence. Though the project teams may not decide to comply with the methodology in one go. Let it be in parts. Let the most essential documents be adopted and adhered to in first go. Get conversant with the benefits and then decide to adopt the next leap of methodology. But whatever they accept to adhere to in first go, they must. All such documents from various project teams should be marked to QA also for audit purposes. A complete adherence but partial flow of information to QA will project wrong picture. QA also has to ensure whether only sample sheets have been sent to them or it is the complete set of documents related to project coming to them.
4. Repository building: QA has to play a major role in building proper repository of project related documents. If there is no visibility and clarity of compiled repository of all documents related to a project, QA needs to be alerted. In turn QA may alert relative project heads for compliance and information flow.
5. Proper Templates Compliance: Confirmation of receiving of documents by QA initially does not imply the adherence to proper formats released by QA. Project teams especially in case of multi projects and overseas projects may not change the formats immediately in between the project and may like to continue with the old templates (or non uniform templates) till the running projects get completed. QA must ensure that all new projects are strictly disciplined to adopt the standard formats in place of any non uniform templates for compliance.
6. Project ON and OFF Trigger: At times there is no apparent visibility of project ON and OFF dates. Respective Project managers need to release formally the project plans and tentative ON and OFF dates. The monitoring agency must be aware of it. QA must be considered as one the stakeholders of the project.
7. Version control: If project managers are not able to control and maintain the versions for their software applications, QA needs to intervene, and they can only intervene if they are involved in the process of monitoring the controlling process.
8. Version Control Methodology: QA needs to evolve exact Methodology or Policy for version control. Project managers are bound to adhere to it after evaluating, fine tuning and accepting it.
9. Product to be released for QC: One of the roles of QA is to enforce QC plan to be an integral part of project plan. This can happen only if the respective project manager is clear about its teams plan to release the product for QC. QC may be an ongoing process (continuous) or in batch mode depending on the nature of project and methodology it falls into.
10. QC bugs: QA must ensure that the bugs reported by QC to product owners must come back to QC in the form of acceptance and feedback. Some project managers don’t feel it is important.
The organizations where QA sits on top of project teams and quality control teams drive projects better in comparison to organizations following any other pattern.
Bug is a common factor between a tester and a developer. A developer creates a bug, tester identifies it, and then the same or different developer in turn kills the bug. A developer has two faces – creator of bug and destroyer of bug.
The intermediate phase is identification of bug which is performed by the tester.
It may happen and it mostly happens that new bugs are generated while fixing the old ones. And that makes this cycle repeatable till all the bugs are reported closed by the testing team or if in between development team decides to withdraw further testing. The second option is quite dangerous as the bugs suppressed will definitely play their crashing role at later stages.
It is always better to connect a bug to its creator, killer and identifier for the following reasons:
Billing: If the billing structure is such that the actual hours spent on the project are directly billed to the customer on weekly/ monthly basis, the time spent on bug identification, creation and closing are important for that purpose.
Time Sheet: The daily time sheet is required to be maintained by software organizations so that they come to know where the employees are spending their productive time.
Project Cost: These costs definitely add up in the ongoing cost of the project. to estimate the cost incurred at any stage of the project, these costs need to be accumulated in the total cost of the project.
Project Delay: Definitely if the bugs closing and testing cycle is repeated many times to bring the product to the expected level of performance, the delay in timelines will count in such exercises.
Performance factor: To evaluate an individual developer or tester at the end of a project, during a project or at the time of appraisal, this data will help in assessment. The developer generating more bugs, the tester coming out with less bugs, the developers taking more time for bug fixing etc. will help in the proper evaluation.
Sixteen checkpoints for Software Project, Project Methodology, Project Management and Project Managers
1. It is important to create and follow a methodology for your software project management.
2. Let your project management not turn into a sad story.
3. Out of a project methodology and adhering to it, adherence is more critical, whatever methodology you design for your projects management.
4. Different software projects may not necessarily fall into the same methodology. So depending on your project type you need to define a separate project management methodology. For instance there might be a difference between your in-house, domestic and offshore projects.
5. An unfit methodology or wrong way of managing your project may cause a retardation in the progress of your project thereby causing a frustration in project stakeholders.
6. The maturity in the way a project is managed decides the success or failure of project.
7. Project management methodology may also depend on the project size also.
8. Don’t let your methodology become stale by not observing, evaluating and redesigning it.
9. Various soft spots or loopholes in your project methodology may cause a number of wrong results in your project thereby deviating you and your teams from the desired progress or flow of the project.
10. A real transformation is required from time to time to keep your project and methodology you are adhereing to – to keep the progress on track.
11. You must be very clear all the time to understand and adopt the real ingredients to keep your project end in time successfully.
12. The project manager has to become maverick sometimes to pinpoint the flaws in project and overcoming them.
13. The project manager has to have certain set of skills to keep his project alive so as to accelerate the progress.
14. The project manager has to have handy checkpoints at the start of a project.
15. The project manager has to interact, interject or do both during the project.
16. The large sized projects have more chances of failures if not managed properly.