A gardener is not a simple job, rather is a most tedious job of growing and nurturing nature. The similar job is that of a project manager who has to manage different teams in a project. The team members comprise of different ages, cultures, geographies (sometimes), experiences, backgrounds, qualifications etc. A project manager has to plant, nurture, care, water, grow, safeguard, and manure his team members depending on the stage of the plant (team member).
1. Nursery: All new incomers need to be placed here for providing them special attention, right direction and extra motivational strengths. A separate set of extra organizational cultural, functional and relevant technical training is required to be imbibed for synchronizing newcomers strengths with the organizational goals.
2. Trees: These are the existing team members for quite a few number of years spent in the organization. They have displayed their strengths, acquired new strengths; deliver at par with organizational expectations with least direction and efforts. One thing that goes unnoticed about trees is that trees strive to show their strength and knowledge by delivering fruits… I mean the people falling in this category strive to train people with less experience, share knowledge with juniors thereby helping in growth of others.
3. Plants: These are the most variant category requiring different stimuli depending on the category they fall in. Some may require extra sunlight, some extra water, some prefer to grow in shade, some need extra nutrients. This is the phase of the people where they neither decide for a long term engagement with the organization nor do they plan to leave it soon. It is the phase of bonding and attachment depending on the way they are treated.
4. Watering: Each plan has different water requirements but no plant can survive without water. Except the trees whose roots are well deep enough to get water directly from the earth. These people (trees) are having a deep attachment and bonding with the organization. As and when they feel low (which happens not to frequently), they themselves fetch energy from the management instead of waiting for someone to come and energize them. Rest for all plants a regular watering plan is must in terms of motivation, training, discussions, recursions, informal engagements.
5. Drive with a top down approach: If the project command is shared with one of the top management member of customer end, it gives a catalytic thrust to the project progress and becomes a winning note for the product.
6. Don’t pass a stupid message that successful business application implementation means decrease in Headcount. Rather pass on the message that the underutilized employees who are engaged in manual processes will be converting to more productive work.
7. Manage Change: Generally change is welcomed with a resistance. People want to stay cool with their regular routines with no considerable change. Any application implementation or process enhancement seeks change. It needs to be observed, controlled and managed wisely.
8. Motivate users: A person when felt as important pillar for a change, feels good and motivated. Engage users to their full strength for the change and implementation.
9. Remove junk: Sometimes an automated or fresh designed application process becomes lethargic and boring than the earlier used process (legacy or manual). Sort out, identify the major chunks of junks and convert them to more friendly and optimized user friendly.
10. Kick Process not People: It is the process or methodology that is responsible to make a success more than the people involved in it. Enhance the process of implementation rather than wasting energies on finding out the weak people links.
Sometimes business applications die an unnatural death even if the application is built with state-of-the-art technology fulfilling all relevant business requirements.
The reason of failure does not lie with the application but the people and processes involved in deploying it but unfortunately even in such cases the blame goes to the application and it is the application reputation that suffers.
The two main defaulters in this case who can be held responsible for Project death are Implementors and End Users/ Customer Management. To cope up with this risk and for mitigation let us work out on the following ten tips:
1. Understand business requirements and pain areas: This beautiful application may be lacking some customer specific areas which are not catered or are catered but not satisfactorily in the application. These pain areas need to be addressed as and when they evolve during the UAT or product implementation.
2. Address critical business processes in the application: Sometimes some core critical business process is misunderstood and built wrongly which is recognized at a later stage. It needs to be addressed either way.
3. Take feedback from users: It is very important to make user feel important in the project. One of the way is to ask for their feedback in a formal manner. It not only makes them feel an integral part of the project but also gives them a chance to speak their heart out. In any case the customer management would definitely be acting on their feedback only.
4. Engage employees and Management together: Many a times the project team forgets customer top management and focus entirely on end users without engaging and updating management.
———contd in my next blog.
Project performance encompasses performance of each individual member of each team working for a project. Each team members requires an environment around him that facilitates him to work towards his goals.
The components of an environment for a team member would be the working place, sitting place, workstation, and general administrative facilities.
Many of the components that may not draw immediate attention of focus but actually playing a role in project performance can be defined as below:
2. The communication process in the organization among other team members and management,
3. The comfort of sitting place, tea/coffee breaks, lunch provisioning etc.
4. The desktop/ laptop configuration
5. LAN and internet
6. Even the power supply, lighting in the office and on the seats, drinking water arrangements, rest rooms etc.
All these factors if are favorable towards employees in turn bring lot of favor to the project performance.
Six Sigma is more of common sense and facts based analysis of real data to arrive at an action plan. The basic steps to perform a six sigma project are as below:
2. Set goals to resolve this problem and define the result in terms of financials and timeframe
3. Collect data for a considerable period to analyze
4. Perform statistical analysis based on relevant tools to identify the core issues responsible for the problem
5. Hit on those core issues
6. Identify and measure the gains
Usually it is not easy to run above cycle once and achieve the desired final results. With the help of interim results in different iterations, the final results can be achieved.
To do that a basic six sigma approach can be applied as below:
2. set a goal of fixing top 5 or 10
3. collect relevant data – very important to understand that wrong or incomplete data will draw out wrong results
4. perform SIPOC
5. analyze the top most (say 5 or 10) factors responsible for your problem identified
6. set a goal to kill/mitigate those factors
7. see the results if you are moving near your result goals
8. analyze next top (5 or 10) factors
9. kill them
10. check the distance from your goals
11. and so on…
A lot about the product architecture and design depends on the inputs of business requirements. The team responsible for business study and documentation must understand the severity of risk built in development stages due to wrong or incomplete interpretation of business requirements to be built in the product.
Business requirements documents include both functional and non functional requirements emerging out during the discussions with customer management and key functional managers. All these requirements become integral part of the requirement document that moves to various teams during the different stages of project development.
What if some of the crucial requirements are not captured during the study phase? Or if some of the requirements are not documented in illustrating manner which in return present wrong interpretation to developers and the product development starts moving in wrong direction.
All such ambiguous/ wrong/ incomplete developments lead to a risk of customer/ user dissatisfaction at a later stage depending on how soon or late the product built is exposed to the customer front. Such risks must have a concrete mitigation plan beforehand in order to not to lose confidence, time and reputation.
Project Manager has to have leadership qualities to achieve success in projects. To carry on with these qualities for project management is good for project manager keeping in mind to regularly improvise and enhance these skills.
Another outlook is to inculcate these qualities in the team members down the line. Being a mentor for few of the team members is important to develop future project managers. Also if the team members touch down the inner feelings of project manager about the project, it becomes easier for all to synchronize their energies and move ahead in the same direction together.
Non Standard processes are prone to risk. So is the service. Service is more based on the people than the deliverables. Even the set standards will vary the level of sam service being delivered by different set of persons. Product is easy to judege in regard to quality. It is instantly demonstrable also in case of a product with the help of measurable parameters of testing.
In service it is difficult to set or establish process standards. Even if they are set, if is difficult to measure them to instantly declare if the service is of high quality, or low quality. With the same quality of service it is not possible to make each customer satisfied. The level of satisfaction will depend on lot of non-measurable parameters.
To outsource a vendor for a specific service, there has to be a checklist with parameters defined to ensure the right selection of vendor for that service. The selection cannot merely be based on gut feeling or the verbal commitments of the vendor. Some of the important parameters for selecting a vendor for a service could be:
2. Customer’s Turnover: Check out the vendor’s record (though he will not be easily disclosing it) how many customers have left him during last three years and try finding out the reasons for it.
3. Certifications: There are world class certifications available these days geographically everywhere. Checkout the relevant certifications your prospective vendor has obtained. Check out how old are these certifications, have all recertifications been done, when was the last audit done and see the audit report to find out the observations or non conformitites pointed out by the auditors. Also check out the reputation of the auditing agency.
4. Employee Turnover: Check out his employee turnover. Beware to outsource him for a service if his employee turnover is high.
5. Growth: Check out the financials to find out the rate of growth. If growth is turbulent or incosnsitent, it could be a point of worry. A consistent or atleast sustained growth is good.
Managing and running helpdesk is not an easy task. Once the project is completed after software application has been implemented and sign off has been taken from the customer. a new journey starts in terms of product support. The users who start working on the product entering real business data to product useful informative reports for themselves and their management face problems in the beginning while working on the new application in the organization.
These problems could be due to many reasons like:
2. hidden bugs in the product being exposed while working
Over a period of time helpdesk becomes a good repository of information gathered from application users in terms of complaints, suggestions, feedback etc. One way of working of helpdesk is to record the problem, provide the solution and treat the story as finished.
Another way to look at it is to analyze this data and find out if there are any complaints that are recurring in nature. Definitely there would be certain problems that would be occurring repeatedly. Providing a temporary solution is good as an ad-hoc provision but getting into its depth later and finding out a permanent solution is very important.
Tasks and Constraints go hand in hand. Life is full of tasks. So is a Project. Project Management consists of lot of planning and re-planning. If everything goes smooth as per plan, there is never a need of re-planning. In real-life scenario this doesn’t happen. Constraints are the generators of problems and problems need solutions. For addressing a problem and providing an alternative to suit as a best possible solution creates the need for re-planning.
A continuous analysis of what is happening around in a project is important to understand if everything is moving as per plan or if the deviation from the plan is going to cause a disastrous situation (or something in-between the two extremes).
The two constraints classifications are:
1. Capacity Constraint
2. Quality Constraint
Identification of factors causing any of the above constraint is of prime importance. Sometimes it is easy to perceive these constraints in early stages and make them part of your risk analysis. The mitigation plan is made accordingly. Sometimes these constraints if not perceived and made as part of risk plan cause trouble when arise at a later stage. If they are encountered at a later stage, it comes as a shock rather than a surprise.
Constraints may arise due to various reasons, some of them could be:
1. Lack of clarity of project goals
2. Lack in project management methodology
3. Non adherence of standard processes
4. ambiguous processes
5. Lack of drive
In a normal scenario testing of a product is done within the organization by the quality/ test team members. Lately as cloud computing came into the picture, a new concept of testing on cloud has emerged, though not many companies have jumped into it.
Testing on cloud carried quite a number of benefits in terms of cost and resources. It is something like “service on demand” or “testing on demand”. The cost of hardware, software, tools, tester etc. is charged on usage basis.
Some of the key benefits that can be drawn from this are:
1. Tool License Costs: You don’t need to invest in tool license. You have varied option of selection of choosing tool of your choice depending on product to be tested. The service provider is supposed to ensure that latest version of the tool is provided. So instead of paying a hefty amount for buying a tool, keeping track of updating it with latest patches and fixes, getting bothered about the new release and then depending on it for all your product range; you just need to pay-as-you-use basis.
2. Infrastructure Costs: To perform testing, to load tool and to provide a substantial hardware/ infrastructure platform in-house; you can go straightaway for the cloud service provider.
3. Flexibility and Wide Range: You have the flexibility of using only when you really require. And you have an option of choosing the right tool for right product.
4. No Setup and Procurement Time Wastage: You can bypass to invest your time in procurement and setup process. straightaway select the cloud vendor, and get the setup already up and running to start testing instantly.
5. Expertise: You don’t need to hire tool experts.
Project Management is involves strategy, plan and intuition. A project may be complex to manage if project targets are not indentified properly. It may be simple to manage if project targets are identified, risks perceived correctly and risk mitigation plan is made a important subset of project.
In a battling ‘software project targets’ situation two major villains that emerge out are lack of time and lack of visibility. It clearly indicates that a revisit and refinement is required in the project management system/ process. The Project management team comprising of all major stakeholders are required to investigate project management practices & procedures and acknowledge the loopholes.
Gaps in project management processes can result in loss of the business to competitors. That is why time investing in building a quality project management practice becomes prime important.
Some important points to take care in that case could be:
2. Manage the entire project cycle from project initiation to project sign-off with involvement of major stakeholders.
3. Monitor the progress with intrinsic insight.
4. Try to identify and nullify time and effort wasting activities.
5. Maintain regular status reports visible to everyone associated with the project.
6. Seek Feedback on project status and performance in every project meeting.
7. Control deadlines.
8. Track expenses and time budget.
Earlier IT organizations used to focus on technology and its synchronization with internal needs. But this focus has steeply shifted to an in depth selection of right technology out of all possible available in the market and its maximum utilization to cater to the end users who in turn use these tools to manage, control and enhance their service to internal and external clients.
This is where Standards come into the picture. Global standards help in meeting internal as well as external customer’s expectations. Standards chosen must be such that they meet today’s and tomorrow’s challenges to cater to the business needs. It should be based most comprehensive and widely accepted framework globally. It should be flexible yet filled with best practices to chalk out your own path to excel in both world’s expectations to help you in delivering the best practices based services.
Like any other large sized product, it has to be implemented in steps. It cannot be done in a single step. A mapping with the existing and future business needs with the best practices available is important for which the needs are to be indentified very clearly and correctly. For any organization, its business needs are unique and hence should be the strategy to adoption of best practices.
The benefit of such an approach is that it helps in ensuring expected level of service with a high level of consistency.
It will also help in achieving highest level of internal and external customer/ employee satisfaction as well as will in lowering in the cost of service thereby increasing business value and reputation.
Project comprises of many functions. Each function’s identification, staging and monitoring is prime during all stages of the project. Function’s progress indicates the progress of overall project. A broken function means an immediate attention. Attention will be possible only if the function is being closely watched or monitored. Else the breakage will go unnoticed and may attract attention at a later stage when something disastrous happens due to this earlier breakage gone unnoticed.
Sometimes a small breakage may evoke and evolve a sleeping volcano to create a major problem.
Function going smooth also indicates no bottlenecks in the project. A broken function means a risk identified that needs to be mitigated.
A smooth closure or finish of a function acts as a catalyst for the next function in the row. A broken function accumulates negative impact for the whole project.
Some broken functions may have chain reaction of generating more broken functions.
Data collected for any purpose is useless in three cases – one, if it is not collected in standardized form, two, if it is being collected just for the sake of collection thereby not doing any analysis and three, if no thought process is gone on analyzed data to improve the situation.
In all the three conditions, the purpose is not being catered to. But let us understand that different organizations in terms of data collection fall in different categories as mentioned above.
The organization falling in first category are just collecting data blindly without any serious thoughts gone into the process. The second category organizations are a little better than the first condition because the data being collected is in organized or structured form but no analysis is being conducted on that data. But in case the organization wakes up and plans to do some analysis – atleast they will have the base data in proper shape.
The third category organizations go upto analysis part but do not draw out sensible conclusions to improve the situation.
But sooner or later all organizations need to fall in the fourth category – that comprises of:
1. Collection of data in proper form
After the completion of a software project, the project closure report or project sign off starts a new experience. The users start practical usage of the product in live scenario. The management starts expecting the useful information in form of reports and screens to manage the business more efficiently. Above all everyone expects more comfort and more confidence.
Though in the initial few months both the users and management may not get completely what they expect. The users comfort will increase gradually as they become more and more conversant with the product in isolation.
This will be a learning stage for them too which will teach them some real lessons that were not covered in training sessions. The problems they encounter might not be technical issues, it might be related to wrong usage of the product. All this gradually evolves and results into a more knowledgeable user.
Management on the other will depend on two factors – the feedback from their key users, and their own experience with the product.
Over a period of time, after these initial struggles, the management, users, and product have to synchronize to get the useful results.
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.