Change is generally not welcomed in any system and is treated as problem. Change management is full of obstacles some foreseen and some unforeseen somewhat similar in nature as that of project management. Project manager need to overcome a number of obstacles and hurdles while project development and implementation. Software implementation is also a part of change management as it requires a number of changes in the organizational culture and its business process.
Ownership, commitment, motivation are three major obstacles that come in way of project manager in terms of the organization where project implementation takes place. Everyone in organization welcomes new software to be implemented for easing out business process functioning but there are equal intensity of resistance too which is sometimes not visible openly though has a full existence in place.
Changes in terms of technical environment are easier to impart during product implementation across an organization as compared to the culture changes. Total involvement with a top down approach works better in any implementations as compared to a bottoms up approach where top management is not engaged in the process.
‘Learning by way of doing’ and ‘Demonstrating by way of doing’ are two important tools for managers to confide their teams during an implementation phase. Just do and demonstrate rather than demanding the same set of action from employees down the line.
This way of implementation increases trust factor across not only among different levels of management and other staff but also in the product being implemented. That way it automatically increases the level of commitment and engagement.
A good writer is one who pays equal weightage to proof reading or editing of his work besides being focussed on content quality and writing style. For every new work that a good writer produces, he doesn’t mind spending some more time on it and getting some different opinion on what he has written. The great author Hemingway always had his books edited and proofread before giving it a final nod for publishing.
Similar approach must be inculcated in a tester too as far as bug reporting is concerned. The way a bug is reported may not be understood or interpreted in the same manner by a different set of eyes reading it with a different frame of mind.
In bug report, a tester knows clearly what is intended to be reported from his end. He might explain about a bug thinking it as the best way to communicate his purpose. A developer on the other hand as a different entity may understand differently to what tester intended to communicate and thus may take a different meaning that may lead bug fixing to a different direction.
Definitely in case of a doubt, when developer seeks clarification from tester about a bug, things would get clearer removing out all gaps in intention of report and its understanding. Bug reporting is always an interactive process. Logically after reporting a bug a tester must leave report as it is without sending it to development team. After sometime tester must come back on the same report that he left, read it as a developer would read it. This way of editing with a virtual different pair of eyes a tester would be able to seal any leaks in his bug report.
Rereading and editing of report is in no way a waste of time or effort comparing it with the time or efforts required later in wake of unclearly reported bugs. In a broader way, it can be treated as a quality check of bug report.
Presence of some particular teammates in their team makes a big difference in terms of team momentum, tempo, confidence and quality of delivery along with high rate of delivery. Some team members are self starters and self goers while others need ignition from others. But there is a rare set of team members who act as team starters and team goers. They have a tendency of working with a wide angle rather than focussing on just themselves.
Those team members have an extra spark in them. They have some typical properties in them that differentiate them from others in the team.
These typical features can be listed as below:
2. Self starters.
3. High achievers.
4. Target Oriented.
5. Consistent winners.
6. Challenge acceptors.
7. Exemplary for others in the team.
10. Down to earth.
Everything does not go as per plan in any project but there are ways to put things right back on track. It is these sort of teammates that make it happen. Such teammates are very strong building blocks for the team. As long as they are there in the team, team keeps going as a single unit producing the desired results in right manner.
Lean and Agile are two keywords being widely used nowadays in most of corporate world engaged in production or development work across the globe. Let us see how these two terms fit in quality assurance and control of software development in software industry. Main focus of Lean lies on flow of development or production of software whereas Agile talks about initiatives taken in adapting change. The difference holds valid for both scenarios whether we talk about software agility or business agility.
In a better perspective if we see, when we talk of focusing on flow, it implies to an effort to inculcate an ability to adapt to a change. On the other hand the purpose of focusing adaptively to responsiveness requires an in-depth analysis and focus on flow. So in a way both are tightly integrated to each other even being two separate entities and may lead to a similar end result.
Agile software development methodology stresses more on highly matured teams. So much so highly matured that there is a very high level of trust between management and teams. The management empowers teams to an extent that none of the management personnel interferes or questions the functioning of teams. Teams in turn give a very high level of transparency to keep noticing team’s regular measurable results.
Most of advanced organizations engaged in software development business prefer to adopt agile methodologies to reap benefits of it in real sense. Lean is mostly adopted in a manufacturing environment so as to gain scaling across enterprise to optimize value stream.
Focus of Lean is on PROCESS more than PEOPLE whereas Agile gives precedence to PEOPLE over PROCESS and tools. Lean is a method of scrutiny of process on a regular basis. Purpose of Lean is to eliminate waste so as to deliver efficiently and quickly.
An Organization and project management cannot be treated as two separate parallel entities in Lean environment. If one is treated as a whole system, another becomes a subset of it. Waste created in organization cannot be treated as a non impacting factor on project teams. Project management teams have to be a component of organization structure similar to HR, finance and others. That way organization as a complete system has to be quite interactive with the functioning process of other sub systems.
There would be two approaches for this whole system and its sub system architecture. One would be top down approach while other is bottoms up. As is clear from the nomenclature whatever approach is adopted, there has to be a clear cut linkage between the whole system and its components functioning as its sub entities.
When forming an organizational structure, all levels must be engaged into it so as to impart or distribute ownership across the board in a proper fashion. Preferably start designing with a bottom up approach, taking into account the core anchor team in the process engaged with customer directly in any manner.
Core work and core teams have to be separated from non-core ones for optimization purposes at all levels. There would be two category of teams – one that interacts directly with customer and server customer, another that serves the teams directly serving the customer.
Once this is achieved, then focus on differentiating between different levels of teams. Different levels will require different performance parameters and optimization procedures. Think of training, tools etc for them.
There is a strong relationship between backlog and estimations oblique planning. In software project management during development phase development team is deeply engrossed in development of product in question. There has to be somebody who needs to minutely analyze backlog at short regular intervals so as to organize development in a very structured manner.
Mostly it is development manager who has to play this role. Every morning for example, development manager need to look at the backlog in the current development basket so as to ascertain actual team size and proper work allocation.
Team size is not a constant. It may vary during development phase depending on additional workload thereby demanding increase in team size or resizing of workload so as to decrease team size keeping in mind the time schedule remains same. In some cases if the workload during re-estimation stage if found lesser in size than the earlier estimations, may ask for two revisions.
One could be resizing of team size that means allocating some of the spared team members to some other project on ad-hoc or permanent basis. In this case the target time remains same. Another case could be where the team size is not reduced and time schedule is preponed.
Regular backlog monitoring helps a lot in estimating accurately thereby demanding a right size of team or giving correct target dates for covering backlog. While analysis of backlog and its scheduling, it is quite important to prioritize tasks as sub-components of backlog in a smart manner.
Segregation of parallel and sequential tasks of the backlog chunk is very important in task allocation to team members,
2. Product backlog needs regular analysis, planning, and re-planning.
3. Product backlog cannot be allocated to development team as a whole.
4. Product backlog subcomponent cannot be given to any of the team members.
5. Prioritizing and re-prioritizing of product backlog components is as important as breaking of product backlog into smaller components and sub-components.
6. Product backlog management works better if done by an expert who knows about product, team members’ capabilities and correct backlog derivation.
7. Product backlog tasks and sub-tasks need to be arranged in parallel possible and sequentially possible ones.
8. Team size and target timeframe are inversely proportional whereas product backlog is directly proportional to both.
9. Development manager is most appropriate person to manage product backlog.
10. A steep inclination or declination in product backlog means an emergency alarm and requires an immediate top management intervention.
Cricket and software project management has no link. Neither has John Wright, the New Zealand cricket team coach. But there are certain things happening around in international cricket that can help as learning for project management. In ongoing series between Pakistan and New Zealand, New Zealand could not play like an international team when their batsmen shattered like a sand dune in second innings. Whole team was out at just 110 runs thereby getting defeated by Pakistan by ten wickets.
Two things have happened after that as far as John Wright and New Zealand team is concerned. John Wright has very clearly and sternly told top order batsmen to tighten their belt and perform their job well without any excuses or explanations. If a specialist batsman is in team, his prime goal is to bat and not lose his wicket cheaply. That is what a clear cut message by the team coach to his team.
Second important step taken by John Wright is to drop opener specialist batsman Tim McIntosh from team and include allrounder John Franklin in his place. It is interesting to note that John Franklin has not played an international test match during last two years or so. But it seems to be a well calculated risk by the Coach for two reasons.
One reason is Tim McIntosh has not been able to touch double digit score in six of his last eight matches played. Another is by taking all rounder John Franklin there will be an additional bowler available in the team in addition to the regular bowlers thereby strengthening the bowling department.
Learning from John Wright, a project manager, under crucial situations has to raise an alert and alarm for his various teams lacking in delivery. Another important lesson is that there is no harm in taking calculated risks provided an in-depth research has been done for its pros and cons and be prepared for it in advance.
Let us take a case of project manager X who is well recognized in his organization for his capability of doing task well and before time, delivering project in time and up to the complete satisfaction of his management and customer, delivering in a quality way. It has happened due to some very good achievements by him as project manager that made his management proud of his capabilities.
Consistency is a big issue with this project manager. He is not able to finish his task well and before time ALWAYS. He can not deliver project in time and up to the complete satisfaction of his management and customer ALWAYS. He does not deliver in a quality way ALWAYS. If he has some very good achievements in his credit, there are more number of failures that overweigh his debit side.
He has some extraordinary qualities that nobody else has in organization but that does not qualify him to take charge of crucial projects due to his inconsistent delivery. Rather management would prefer to handover crucial projects to some other project manager posing less risk and threats for its failure or delays.
Even if management decides at times to hand him over some very crucial project, it is with a very high risk at the back of their mind and a careful attention towards Mr. X throughout the game.
A steep graph on both sides of his performance makes it quite a risky affair for management to decide giving him projects with a hundred percent assurance of success.
What will be your call in deciding as management executive for such project manager?
Bugs are a gentle reminder to respective developer and a sort of alarm for him to check nothing has been skipped as per user and business perspective. Bugs also act as useful and productive communication initiators between tester and developer till the individual loop gets closed either by execution or rejection of a bug. Bugs should be just on surface as close to the product developer as possible. That way it would be quite sensible and meaningful.
A tester must check the purpose of bug reported before submitting it in his/ her list of bugs. A bug is meant to highlight non easing spots in the software built where end user may feel uncomfortable to work. These spots need to be relooked into by developer so as to improvise on it.
An unnecessary or non purposeful bug may act as nothing but an unwanted noise in the sweet tunes of product built. It not only wastes time of tester but of all associated within bug lifecycle chain. These sort of noisy bugs reported may also act as distance creators between tester and developer which will be of no use to anyone in the teams.
Tester must be very cautious while report a bug which itself loses its sanctity being distant from the primary goal or purpose of a product or software.
A tester before adding or reporting a bug in his/ her list of bugs must be very clear about the gravity of problem being reported. As far as possible he/ she must add only those bugs which he/ she is very much clear about. Preferably while reporting a bug, a tester with his/ her knowledge of product being tested must propose a possible solution to development team which should be clear and crisp in nature. If development team finds it useful, there is no point they will not be in agreement to tester(s).
A bug reported goes meaningless most of the time if it is not clearly stated with an indication of benefits from its fixing.
Business value is not easy to ascertain, sustain, manage, monitor and improvise upon on a regular basis. But it is very important to do so. Somewhere sometime during my career one of my seniors advised me a very harsh truth of life. It was – “you cannot sit on your laurels”. What he meant was that everyday is a new day with no credit and debit from previous day.
The past successes cannot be celebrated for in present in lieu of current day’s laurels getting missed. Everyday is a new journey and hence new achievements need to be established on each day.
The same applies to business value too. Past peaks cannot be accumulated in current business value. Whatever has been achieved in the past has been delivered to the customer and hence cannot be treated as a new delivery today. Something new, fresh and better is required to achieve further enhancements in already established business value.
No accumulations are permissible. A classic example would be customer support. Your customer’s loyalty towards you is in lieu of consistent support given to them.
A regular good support given and customer loyalty gained in lieu of that will certainly abrupt the moment there is a downfall in support delivery or quality of service given to customer. Similarly you cannot expect loyalty from a customer who is not so well supported and in a way feels ignored from you.
Business value is a two way process.
Business value is never a constant. It changes with time. Its parameters also may change from time to time. A factor which could be inconsiderable a certain point of time may emerge as a considerable factor to be included at a later stage. So that means the number of factors and particular factors may vary from time to time to evaluate and assess business value.
A benchmark for business value always helps to spearhead and aspire for best. Business value evaluators and committee decisive about factors must have a plenty of knowledge of business otherwise the effort may go haywire.
For example good software is launched in a company which is not able to use it as they value more to the legacy software in use. The product launched may have a great value in market and in other businesses but here in this particular case in this company the product has no value though it has been bought and paid for.
If users and management here do not care for the product or use it, it cannot be treated as a good launch or productive sales if both the sides are taken into consideration.
Some factors may have more weightage than others in many cases.
There has been a long debate for many decades regarding quantification of business value. Is it possible to really quantify business value? Perhaps the answer would be no from most of us. Reason being it is actually not possible to quantify hundred percent. And probably the efforts involved in quantifying it would exceed the benefit without reaching to a purposeful state.
Even a whole heartedly effort is sincerely put into quantification of business value, it will never be possible to quantify it completely. If it is done based on certain assumptions, then obviously assumptions will play a major role in the results.
Though there will be some direct and indirect consequences and factors that could be directly and completely quantifiable. One example could be a high selling software that meets business requirement of most of customers would lead to high revenues and returns since there will be high demand for it.
Moreover if the same software is so highly bug free that it does not let users raise any doubt and problems then its market demand will rise further due to its good reputation. This can be treated as a quantifiable factor like revenues and sales. Moreover another factor of number of complaints reported by its users over a long period would be negligible and hence is quantifiable.
Satisfaction level in such a case would be very high among its users if a survey is conducted. Such a survey with realistic data can help in further boosting its sales among new customers.
We usually don’t evaluate a change request or requirement in accounting terms for both its purposes – expense cost and benefits value. Maturity of change management process depends solely on the organization that incorporates any change management process and its periodic evaluation.
The process adopted at one moment of time may not be as effective and useful the next moment. That is why a regular inspection and objective evaluation of any process makes sense to understand the maturity level of the organization.
Enhancement in any process at regular intervals also states the speed with which any organization would be maturing.
One way to look at a change or new requirement is the estimation of cost involved to incorporate it. There is another way to look at the benefit an organization gets after incorporation of that change or new requirement built as an add on to the existing application. Benefits could be in terms of time, manpower, accuracy, satisfaction of employee and customer; and so on.
A famous quote by Norman R. Augustine goes like this – “Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases.”
This one or two liner quote says a lot about the practical world of software development. And the story remains same globally more or less with a small variation. It is true that whatsoever approval processes you adopt at customer location during requirement analysis phase, some of the requirements always remain undocumented and unapproved.
Even with the involvement of all concerned in a business process, something or the other remains untouched, unnoticed, unrecorded, unmentioned and missed that comes into limelight only at a later stage such as implementation of software.
Better way would be to keep studying business throughout the development phase of software. This way could give you two way benefit – one, keeping customer’s key users engaged all through the journey; and second, getting each small phase of development vetted by customer management and key users on a regular basis.
This helps in avoiding any last stage volcano bursts and explosions.
Let us start with a famous quote by Dave Barry who said – “Software is usually accompanied by documentation in the form of big fat scary manuals that nobody ever reads. In fact, for the past five years most of the manuals shipped with software products have actually been copies of Stephen King’s The Stand with new covers pasted on.”
What does it imply?
Does it mean that software built and deployed does not require any manuals like fatty documents?
Does it mean that the manual instead of being a fatty boring document that is hated to be touched or referred to should be crisp and crux in a way that is really serves the purpose of a handy tool in case of trouble?
Does it mean that hard documentation era is gone now and users prefer to refer to on-line manuals or help contents?
Does it mean that the software built should be so powerful and strong that it does not really require a support document on how to drive it?
Are these manuals prepared really done seriously or just for the sake of formality only?
Does your manual invite suggestions, feedback, or shortfalls to be notified by your users? Do you take a serious note of such engagement of end users?
There need to be standard policy to manage a new project. Policy definition becomes prime important right in the beginning of a project that needs to be approved by management to proceed ahead in further project related activities. Once it gets properly defined and approved, its implementation is the next step. Only implementation does not fetch desired results in most of the organizations unless those are specifically very well synchronized with each and every employee self driven in right direction.
In all organizations other than those ideal ones defined above, after policy implementation, its enforcement becomes next important task for the organization. For that probably an awareness program could be held up in a physical or virtual environment to bring every one into sync.
Once it is implemented, enforced and deployed in an effective manner, its maintenance or sustenance should be the next goal of organization.
If you are successful in all the steps only then the mission can be treated as successful. Hundred percent successes of some steps and similar failure of other steps involved in total deployment of any policy may sum up as an overall failure of any policy.
A policy once defined and approved need to be launched in a proper manner so as to target all relevant team members and should equally involve some key top management persons strategically to make its deployment a grand success.
Change management takes care of any change in the organization that may or may not be directly connected to project. Change management and improvement initiatives may overlap most of the times. Reason could be the goals being taken to be achieved in any improvement process that seek some change in the organization.
Benchmarking, training, formal discussion forums, brainstorming sessions, workshops are some of the result oriented steps taken in an organization for the purpose of alignment or different brains present in the organization. Some of these platforms are best to address some common concerns.
Some of these platforms should also invite suggestions, complaints nad feedback. If these are not taken in negative sense and after well understood, these can be treated as most effective change agents.
There is nothing called shortcut for success. Change agents or improvement initiatives can not change the world drastically or produce significant results in a short span of time. Many a times improvement initiatives fail in organizations for such reasons.
Organizations initiate improvement processes for many purposes. Improvement process initiatives are like investment. Investments initiatives have various goals – short term goals, mid term goals, and long term goals. Same holds truth for improvement process initiatives too.
Organizations taking improvement initiatives are not always better than organizations that do not take any initiatives at all. Reason for this can be understood with two terms which are totally opposite to each other – acceleration and deceleration.
An organization taking an initiative but resulting in a failure achieves nothing similar to another organization that did not take any initiative. Sometimes initiatives taken are not bad but agents driving those initiatives may fail to focus on right targets of initiatives.
Change agents may be internal or external. A complete synchronization among all change agents is very important to get best results out of change initiatives. But overall whatever is the position of a change agent may be, it has to be effectively meaningful and purposeful for product users.
When a project plan is formulated in any organization, the purpose of exercise is much deeper than just defining a project plan on a piece of paper. A project plan can be further used to produce key performance indicators (KPIs) which in turn point towards the achievement of each goal defined in detailed plan. These KPIs can be taken up with two approaches – one can be top down approach where organizational KPIs are broken down further into each team’s KPIs which ultimately further get split up into each individual’s name.
Another approach can be bottoms up where it will be reverse of above. Each individual’s targets or goals become team’s goals. Each team’s goals further get compiled to form organizational goals. Similarly individual goals can be linked to individual’s KPIs. Team’s goals can be linked to team’s KPI. And organizational goals can be directly linked to organizational key performance indicators.
These key performance indicators are purely objective in nature which have to be measurable with the help of some pointers that define factors like success or failure against each one of them.
Each individual in an organization contributes towards its culture. Sometimes interests create conflicts among different members of a team in an organization.
Without bothering about organizational goals putting efforts in designing a framework for project management would be inappropriate for both streams. An individual is always different from a collective group in an organization. It is organization that rules over individual interests. That does not mean an individual has no entity in the organization but what it implies is that each individual’s collective and synchronized energy forms organization’s energy.
A good strategy can be formulated with help of in-depth analysis of market, competitors, customer’s geographic location, customer’s country political situation and so on. With help of all these factors a refined strategic plan can be designed for each project to take place for different customers customized for each one of them.
Without a proper plan no project can take place in any organization. Refinement of plan comes through two main factors which are organizational strategy and customer’s expectations. Planning is important for carrying out a project to give a commitment in advance before start of the project.
If a non adherence in processes and procedures is noticed at any level of project management, it needs to be addressed to by way of understanding why it has not been adopted. The team not adopting it might have certain doubts in mind which need to be understood and addressed to. A fear factor also plays a major role in non adoption of standards. It could be fear of losing importance, or job or anything else. But earlier such glitches are noticed, the better it becomes to clarify management’s stance and let it be adopted universally.
A checklist also can become handy in managing adherence of processes and procedures related to project management. Checklist must be prepared in such a way that it indirectly catches all hitches lying in mind of any team members for adoption of those processes and procedures. It acts as a virus also in most cases. If one team members see another team member violating or ignoring standard processes, it may lead him towards doing the same.
If such non adherence pattern spreads within a team, it becomes not too difficult to spread it across various teams and other team members.
In any case the purpose of process and procedure must not be torturing team members by demanding more time, more paper work or more approval channels in streamlining a project thereby making project management a difficult task.
A link between performance management and processes becomes helpful for any organization to achieve successful results at any stage. A common set of documents available readily becomes helpful in placing all involved at a common platform thereby removing any doubts, ambiguities or scope of non standard process adoption.
A good alignment in project process and business process is also very important to achieve targeted results else what happens later is that two start moving in different directions thereby leading different teams to target different results depending on what process that adopt. Like functional and technical experts there need to be some exclusive process experts at various levels of project to cater to the process needs of project management. Process experts help in two ways – by helping others to become conversant with process and by monitoring various teams’ adoption level.
The purpose of monitoring is not penalizing or pin pointing certain members not adhering to processes but to keep a watchful eye on various project teams and encourage them to accept these processes and procedures by heart and by mind.
A horizontal and vertical involvement of all concerned in project management processes and procedures becomes very important. These concerned persons may also be termed as stakeholders and may vary with their existence at various levels inside and outside the organization. All stakeholders must be well aware of the existence of standard procedures and processes related to any project.
Well defined processes and procedures documented and distributed to all must be harnessed for strategic long term benefits. This is important to achieve and is possible only by way of adherence to what is documented. A continuous adoption of such well defined processes and procedures will definitely help in understanding, optimization and finding out gap between benchmarks and currently adopted processes and procedures.
Once these processes and procedures are deployed by way of providing documents by way of hard copies of publishing on a whiteboard on internet, it helps all to clear doubts if any in mind of any of the persons on distribution list. Welcome any suggestion, feedback, queries or comment from all readers of these documents.
These documents if available readily become a good ready reckoner for any team members anytime anywhere in the globe. Different teams sitting at different geographic locations may need to refer to certain set of documents available to be referred to.
Project Management requires some disciplined processes in place that match, or if they do not match, then strive for best world class practices. These standardized procedures’ documentation is quite important for the sake of clarification, reference, uniformity and removal of any ambiguities.
Let’s see how documentation of standardized procedures is possible. There would definitely a project management committee in any organization taking care of projects. It is not very important to have a formal foundation of such committee. Sometimes an informal formation of such committee without spearheading boundary lines is much more successful and effective than a formal one in place.
It becomes the responsibility of project management committee or in other terms known as project management office to own the responsibility of drafting, documentation, approval and deployment of processes and procedures related to different phases of project management.
A well defined process does not mean that that battle is won. The worst and most difficult part is the execution. Worst for those who plan for follow a process half heartedly or who don’t mind a easy going deviation from a well defined process to a user driven process. Organizations may feel good at the completion of processes getting well defined. After that the difficult path starts of the actual adherence to what process talks about.
Organizations that urge for best practices learn gradually the art of harnessing the well designed processes for the purpose of long term benefits in a strategic manner. Customer requirement management involves number of teams and is never done by a single person in an organization. Performance management of each team and team member involved in customer requirement management can be linked to process for the purpose of successful and fruitful results.
This clearly implies that process management and performance management though may be treated as independent activities but subsequently can be treated as subsets of customer requirement management.
The important part of customer requirements management is to uncover significant hidden factors during the cycle for the purpose of improving processes permanently. There is no end to improvement. Any enhanced and optimized step in the process can further be improvised upon to fetch better results out of it. Documentation and process optimization is as important as having some hands-on techniques already deployed or that can be deployed at the earliest.
A slight shift in the focus can sometimes do wonders. It can transform a complex process into a simpler one. That can happen with the help of improvisation, enhancement, innovation and proper usage of knowledge curve.
Mind it that to redefine any process, never do it just like that for the sake of redefining it. Rely on a well researched process of selecting the part to be redefined from what to what. A proven and pragmatic method will be a winning shield for that.
A significant improvement can be clearly seen in terms of requirements identification process, differentiation improvements from new requirements, calculation of mandays required to cater to new requirements, payment process for new requirements, billing cycle, allocation of requirement to a developer or set of developers depending on the volume of work involved and timeframe, information flow to customer regarding the same, and improvement of service quality.
Customer need to be involved with a right process of communication right from the moment a requirement is received. If the requirement is genuine and accepted, customer need to be informed about the ticket number, the time required to build that requirement, testing of new build, integration of new build in the existing product and handover to customer.
If customer is engaged throughout each stage of the requirement that makes real sense and keeps customer updated and satisfied.
A well defined system in place for customer requirement management always keeps any organization in a gaining stream and there will always be a buy-in for the involvement in that system by customer. By bringing service providers on board, a customer knows, is always for the betterment.
The main factors that get enhanced or optimized through above would be:
Customer requirements not only need analysis and development but a proper deployment process also. A suitable set of launch strategies is required to be in place.
An ecosystem in place for managing customer requirement can do wonders for any organization dealing with multiple customers. The system works even if you have only a single customer. Purpose of the ecosystem is nothing but to make a system more versatile, stable, structured that side by side always strive for the best or excellence.
A metrics in that aspect would always be helpful for analysis and monitoring purposes. Without an ecosystem or metrics companies do survive and keep catering to their customers but not for long if they aim progression and growth in future.
An ecosystem must talk about the minimum requirements for success. A well defined success criterion and its measurement objectives would be a boon for any organization and it leads to a successful proposition for both thereby creating a win-win situation.
Prime important would be that the requirement raised be mapped with a business model in case of functional or business process change request in the product. The business functions it must perform need to be analyzed for priority purposes. If not important the changes can be safeguarded by not performing them in a stable product for the time being.
Changes required would also depend on the type of infrastructure available. The roles and responsibilities of different team members also need to be previewed before assigning a task to anyone.
Once the change request of requirement gets approved, it is better to define formal detailed specification of requirements. The document should clearly define who all are required to be part of planning process and owner of the process.
A viable ecosystem needs to be built around the change and request management to cater to the requirements in a structured and systematic manner.
It is important to analyze any change request raised by any of the stakeholders of the product in a systematic manner. The best way would be to first differentiate business process or functional change with cosmetic or design change. Though both categories can fall into severely possible, easily possible and not possible sections depending on the change required.
For instance, design of any product is dependant on the programming and designing tools used. Programming tools and designing tools also have their own strengths and weaknesses. Based on the initial requirements from customer or market, the development team after introspecting their team expertise and product requirements decide on the architecture.
Hardware shortcomings can be overcome easily by way of upgradation or replacement even if it comes into limelight at a later stage, though that will cost extra. But software development tools and database once chosen are difficult to replace once the development and designing of product covers a substantial distance.
In situations when the requirement generator cannot be ignored directly due to his potential say in the management, the role of Product Owner become prime in tackling the situation. Product owner must analyze the situation, prepare a case study and put forth his point that if such a change is incorporated, it might go wrong for the business and product.
Though it becomes tricky to handle such users but it is important to manage the show.
The project manager must manage such situations by way of convincing top management regarding the misinterpretation of product functionality or wrong expectations from product at a later stage when it has been launched without giving an air of such requirement in the beginning.
If logically put forward in an open platform with a document or presentation explaining how the requirement is already being met in the product but in a different fashion, or the requirement if incorporated will derail the product which is running smooth as of now or the requirement does not make any sense at all.
It is better for a product manager to be open and blunt at such situation when unnecessary requirements are being imposed on the product just for the sake of putting pressure, using influence or imposing ignorance.
Customer requirements management with a metrics is an important factor. Requirements raised a various levels within an organization has nothing to do directly with the seriousness of requirement.
Some key users or management executives though may not go into the depth of the product they are supposed to use but to mark their impression as if they are the most serious users, they do not hesitate in keep talking about the product as and when they get a chance.
Mostly such sort of tricks produces positive results in favor of the person who is playing it. But the positive results are only in favor of the person, not favorable for the product. In such situations person may impress product owner to accept the changes required or the requirement generator is such an influential person in management that you can’t ignore what he demands for.
A proper understanding of any change required and its in-depth analysis are prime important factors. It doesn’t mean that the importance of other steps performed afterwards – like the development of change, testing of all kinds, etc. The later steps are equally important but since it s a sequential process, each of the previous step’s correctness ensures much better results at any stage.
For that purpose if some best practices are identified and implemented well in time to cater to the matter discussed above, it will definitely help in achieving better and faster results. Some development, testing, analysis and implementation tools can become handy to enhance the process and to achieve higher goals.
Automation of some processes is required but what to automate and how much to automate, that clarity is absolutely very important rather than just going for a full automation which could become a cause of another disaster.
A new requirement development done in already consistently stable running software may do certain good or harmful things in turn. It may turmoil; destabilize the software thereby resulting into an inconsistent and unstable product. Which in turn may result into unsatisfied users who were happy with the product before the change was performed on the product.
On the other hand it may change inconsistent software into a better performing and stable product thereby converting so far unsatisfactory users to satisfied users. And a last proposition could be that the user is already having a good software and this is quite satisfied with its consistent performance and results.
With the change applied on the product, it gets further enhanced thereby increasing user happiness to a delight level which is absolutely a win-win situation.
Nowhere it happens that an application serves to a customer needs for long without discard, alteration, overhauling or extended features additions. It is because we live in a world of change. Business needs a change in its process, functionality and control procedures for betterment. And that is why a change in the application or change OF application becomes important at that moment of time depending on the gravity and volume of changes required.
A new functionality if not possible to develop or build in the same product can be delivered to customer in a different way. A new sub-product can be built using the same database as the original product in use but the new functionality built is integrated well with that. It may be otherwise also.
The product in use, if not able to cater to the new requirements or the major changes may call for an altogether build of a new product comprising of a new database and application but limited only to the new requirements and changes. In that case also the two products will be required to be integrated to cater to the overall needs of the business.
The limitations of catering to new requirements may arise due to certain other factors too which might delimited at a later stage or may not be possible at all. For example an application built on client server architecture if required to be converted to a web based application later may call for a major overhaul or maybe a total discard of the already built application.
In that case a total revamp of the current application will become a necessity and a new application will be required to be developed on a different architecture. Sometimes the development tools used in the application also become a big limitation.
In no case any ad-hoc changes should be applied on an application to be used by end users for long term. The development team and the product owner must understand that ad-hoc changes are always meant for a short term.
They are usually provided to cater to customer’s needs for a short duration and during that duration a parallel exercise is done to change, alter or rebuild the product according the customer’s requirements or major change request in such a manner that the product caters to customer’s needs for a long term in a stabilized and established manner.
Sometimes it might happen that the requirement by the customer exists in the product but in some other way. For instance the software product in use might be handling the same requirement already but in a different manner.
In that case a person with good business knowledge knowing equally well about the product’s capabilities need to educate the customer about the feature already in existence but not understood well.
On the other hand sometimes customer may demand which may not be possible to cater to in the existing product perimeter. The original scope of product development well understood at the beginning of the product development might have followed a different direction and the scope of enhancement to that extent might be very limited at a later stage.
Interestingly if the changes are accepted without proper analysis it results in delays in delivery, improperly woven product, un-tested product, shaken budgets. This all happens due to a later stage discovery of the change appearing not as small as anticipated earlier.
So many ambiguities arise if there is a gap between customers stated requirement and understood otherwise at the other end. Customer is never wrong in stating and demanding a new requirement of a change request.
But on the other hand it is the technical team that is clearer about the technical architecture of the application and its enhancement capabilities. It means that a requirement stated by the customer might be of high business value but not related to the current perimeter of product capabilities. Or it may be that the customer is not fully aware about the already in use product’s capabilities and functionality and might be demanding something which is already existing in the product.
Customer requirements at first instance may all appear essential. Especially the requirements listed by the top management tend to automatically fall in must-do category. But that is not so. Any requirement if without proper analysis is placed in must-do or essential requirement may create a big problem in terms of scope and budget of the project.
A simple requirement appearing as a small requirement may have a deeper impact on the product and may require much time in building and integration than expected or estimated. For instance a small change in the employee master database will require lot of efforts by developers in adjusting this change in various screens and reports.
The management might be right in asking for a small change or a simple add-on in the application. The technical and business analysts are actually responsible to do an impact analysis to understand the actual time required to address to that customer’s so called ‘small change’ or simple ‘add-on’.
Let us summarize some thought process involved in Release Management.
Release management is about managing your product release.
A checklist of the kind as below may help in a better management.
How do you manage your library to control different versions of releases?
How do you associate the knowledge, communication, updates, upgrades, requirements along with a release?
How do you associate the team members involved in a particular release?
How do you take control of documentation related to a particular release?
How you associate actions in various releases?
How do you decide to upgrade now or later about a particular release at a particular customer place?
What differentiates one release from the other?
How do you differentiate between a global release and a local release?
Do you differentiate between a country specific release and a business specific release?
The risk management and change management are two major players in whole release management process. Release management in itself demands a complete product transformation lifecycle management.
The risk mitigation plan depends on how critical the application is for business and also on how much dependency is there for business on this application. Higher the dependency, lower is the permissible downtime during the running of production server.
Once the business is totally dependant on an application, it cannot afford to incidents like low performance, unavailability, wrong results, delayed response etc. More so when there is no alternative provisioned by the management, the reliability and availability of the application carries a very high stake.
The management then keeps a highest level of assurance to keep its key users and business stakeholder’s expectations intact.
Once the assessment is validated, the product is ready to be installed in a separate server to run if for real business in real-life scenario. This server is supposed to support the business transaction in real terms. The configuration and other parameters are selected keeping all these factors in mind.
This server is termed as production server. The production server is almost replica of staging server. The key difference between a staging server and production server is mainly that of sizing. The staging server is supposed to handle real-like scenario whereas the production manages real business.
The performance, load and peak testing are once again performed during staging server to ensure that all business scenarios will succeed when the staging level is crossed to production level. The shifting of staging to production is planned and scheduled as per the users comfort so that least business is affected.
This matters more when the production server is in place and later from time to time the new releases, patches, updates and upgrades. The business cannot stop during all these activities. Every such update is critical and risky in a way that if something goes wrong, and the application behaves abnormally, there should be an immediate plan to roll back and go back to the previous stable position.
As the test team finishes the testing process, submits the report to development team, and finally ensures that all test cases pass, the final code is installed in a different server termed as staging server.
This is the server for the purpose of UAT (user acceptance test) for the purpose of using the product as per user and business requirements simulating the real business scenario to evaluate and validate that the business purpose is served perfectly by the product.
The product is evaluated also for the operational purposes. It is evaluated during this stage that it suffices the purpose of product in mass usage when the complete business starts using it through its relevant key and other users.
It is used in the same manner as the real business would be using it but at a smaller user-base. But it is taken care to do a complete coverage.
Though many development teams do not understand the importance of testing the product on their own, but it definitely helps both teams (development and testing) to a large extent in refinement of the product.
A regression test is performed by testing team going for a complete extensive and exhaustive coverage of the product. A well suited set of test cases are performed by testers to ensure each test case is run with pass or fail status.
The test environment ideally should be built in two different servers (replica). This is done ideally to have a complete coverage surety without missing any area by either of the teams.
Test teams run their test scripts as per the test plan and test schedule. The plan and schedule is derived from the requirements of business and customer. The process is unquestionably followed and managed through change management.
Release Management is a journey of software product starting from requirement gathering, product conceptualization, prototyping, coding, testing and finally landing to production server. This product inception and production journey starts with developer’s machine to development server to testing server to production server.
After developing and completing the code, development team hands over the product to specialized persons for performing unit test, integration test etc. to that the product can be formally handed over to testing team for regression, performance, functional and load testing.
A test server is built for this purpose creating a similar environment as that of the one going to be used in the real scenario (production stage). The code residing in development server is replicated or reproduced in test server for the purpose of testing.
It is always better to perform some good level of internal testing by development team before releasing the product to testing team.
Generally in a product support group the end user call is closed by a support executive. This sort of process misses out two important factors – the customer or end user and the quality group. A call closed by the support executive neither mostly gets it vetted by the end user nor is there an independent verifying agent involved in it. The system poses a dicey situation under such circumstances. The process calls for a modification to enhance it to such a level so that the above two setbacks are covered in that.
Risks involved in these circumstances are high and will never let the support centre reach to a satisfaction level. It will also keep raising a high level of dissatisfaction at end user level.
To mitigate such risks the process needs to be enhanced. The best way is to get following 3 points deeply engrossed in the process and without these 3 points activity no end user call should be allowed to be treated as closed. These 3 points are:
1. Get customer feedback: Have a small 2 or 3 questions mailer after every call closed to be filled by the end user to ascertain her satisfaction level for the last call closed.
2. Embed Quality for closure: Include quality executive in the call process loop having a responsibility to close the call. After the support executive closes the call, let the quality guy call the end user and confirm about the call closure and also quickly get his satisfaction level feedback on it.
3. Regular Analysis: A close monitoring of calls during a week, fortnight or month, their status, the open calls beyond permissible time limit, customer feedback etc.
A geographically scattered user base requires a well equipped support or call resolution centre to cater to their problems. A well launched product will never give troubles will be a misnomer. Any level of users at any stage keep encountering issues, problems, doubts, and usage related concerns. These need to be addressed by a team of persons having a good functional and technical knowledge of the product for which they are meant to provide the support.
In a wide country of different logistical user base using the application, there are different ways of handling their issues. One way is to group these various locations in small segments and provide them a group wise support team. This could work well in satisfying the users but could cause problem in looking at the scattered and localized data at a wider angle. Data accumulation, mining, digging and analysis could be a big headache for the product support manager to understand the product related issues. Since there is no common platform where are data is getting accumulated, the analysis of improperly gathered data lead to wrong conclusions regarding finding out the major pain areas of the end users. This would also lead to the wishes and whims of the local support function to decide whether they collect all complaints properly or keep missing lot of them. A wrong platter of data from various support centres may not be fruitful.
On the other hand a centralized support centre providing to support to the end users scattered across would be useful in maintaining uniformity, useful data collection, and proper analysis.
Support or handholding phase starts in a project after the project is handed over to the customer for real-life business usage. The end users start exploring the strengths in the software by performing their respective functions on the product. During this exploration period they do encounter the weaknesses also hidden in the product. The actual experience of end users on the product results into a different set of issues related to product which mostly is not pointed out in any phase of testing.
At this point of time, since the production server is live and the business users are realizing the product’s capabilities and shortfalls, besides running the application to draw out business expected results, the problems reported cannot be delayed for providing a solution.
The support executives have to understand the gravity of each call of the end users to make it a point that the issue reported need to be resolved within the agreed upon timeframe. Some issues reported might be irrelevant in the beginning due to the fresh interaction of user with application, but those can not be ignored.
The Support function schedule need to be fine tuned for optimization purposes keeping in mind the following points in mind:
1. Be objective
2. Define accountability for each member
3. Restrict deviation from schedule
4. Make unreasonable deviations penalized