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
1. Always strive to perform better manual testing (in the manual testing area).
2. Code and Testing are not two separate entities. A Coder can and should take as much care as possible of not embedding bugs (knowingly, unknowingly, carelessly or for whatsoever reasons) in his code.
3. Follow a proper methodology in testing. If it does not exist, stop all testing, get it framed first.
4. Manage tight schedules smartly by not compromising with the quality of testing.
5. Quantify risks to make everyone clear the shortcomings of testing with over-tight schedules.
6. Different phases and types of testing require different approach. One approach does not fit everywhere.
7. Test automation is not always beneficial; it has certain shortcomings too, varying case to case.
8. Quality is integral part of product or software supply chain.
9. Identify, plan, manage and mitigate testing risks.
10. Try to make Quality as an asset rather than overhead cost.
11. Focus on quality of project documents also to maintain the decorum of project.
12. Don’t expect too much credit for imbibing good quality in the product, which is what we are supposed to do.
13. Follow a metrics for your processes and methodology to understand the shortfalls.
14. Create quality rather than product.
15. Testing centre of excellence is not a hypothetical state, live with it.
Support function in a project after the completion of the project. Project sign off includes a successful ending of a journey beginning with business requirements study, development phases, testing, training and implementation. But the actual journey does not end here. After the project sign off, a stage by which the user and customer management have respectfully reflected their confidence in the product built for the purpose, but the actual hand-shaking (or fight) of end user with the product starts from here.
This is the time when in absence of implementation team, for the first time, the end user is starting using the product, all alone, on his own. All knowledge gained so far, by him, during the implementation phase, along with the supporting documents (user manuals) are the sole weapons left with him to win this battle. The initial phase of this familiarization with the product in isolation is really like a battle.
This is also the time when on a parallel spree back office support function starts for handholding the end user’s issues being encountered. In the beginning, since the maturity level of end user on product usage is not too high, some of the problems reported may appear to be absurd to the support function team. But they have to understand the reasons behind this and handle the situation accordingly by putting an effort of educating the end users to guide them for using the product in right manner.
The maturity of issues reported to support team will gradually improve as the usage of product and acquaintance with product increases.
A newly built Software application has to pass through one very interesting testing phase known as Usability Testing. This testing is more focused on finding non functional issues related to the application. The focus is more towards the end user who is going to use the application and not the management who is going to reap the benefits out of it. Ease and comfort, navigation, simple architecture, etc. are the relevant areas that are looked into while this testing.
The end user is the most suitable candidate for performing this testing. But if not available, then the developer or tester who perform this testing must put themselves first in the end user shoe before they start conducting the testing. The end user’s overall experience of using each relevant screen and report are the major concerns. Overall the application may be quite strong but if it does not make end user comfortable regarding its usability, it is prone to win over the management.
The design of the application has to be fit in the end user’s perspective for looking good as well as the professional touch in each of the screen and report. Five most crucial parameters in this aspect could be:
1. Intent of delivery: Try to fill in the gap between the end user’s expectations and the actual delivery.
2. Navigation: This is the area which could give most delightful moments of satisfaction to the user or can kick back in shape of user’s frustration.
3. Response Time: The application screen or report loading time should not go beyond user’s perceptions. A user understands very well about the heavy data centric screen or report versus the lighter ones, and prepares himself accordingly for the output. The users have their own experience with the other legacy applications in use or certain applications they use in person.
4. Cleanliness/ Alignment: The screen should soothe the user rather than presenting him with a non friendly positioned data labels. A symmetrical alignment, non cluttered placement of all components of the screen should be well planned for designing purposes.
5. Nomenclature: Keep in mind what terms end users and customer business are most familiar with regarding the similar labels being used in the application. For example if you post a label “employee’s card no.” and the customer denote their employees in all business records as, say, “associates” then your label should be “associate’s card no.”.
It depends exclusively on you whether you are driven by your circumstances or take command of your circumstances. We all encounter negative forces around us from various persons, situations, circumstances, and failures. Do we get bogged down by these negativities surrounding us or we tend to mould them in our favour, all depends on us. Negativities are unwelcome though but can not be avoided. Best way is to learn a lesson from each negative force to overcome it and change it into a positive factor for you.
A project manager has to face lot of hurdles during a project. A single person in the centre point has to face many fronts in terms of teams, management, peers, customer, project board, and stakeholders. Despite all hurdles he is supposed to keep his tempo up and maintain the momentum of the project progress.
It is not easy, though, to cheer up all around without first keeping yourself with high spirit. There are certain negative forces around the project manager which need to be mastered to play with and win over. Some of those could be:
1. Criticism: Criticism arises out of two situations – one could be due to a fall back in a task or achieving a milestone. Other could be the situational, intentional and irrelevant. Both can not be avoided. Some people have a tendency of raising unnecessary criticism just to stay on top of others by using their power. Learn about the situations, people, circumstances and failures that tend to invite criticism. A proper analysis of each such instance will definitely improve your learning curve towards handling such situations and give you knowledge and strength to handle such in future.
2. Self Assessment: Keep assessing your process, procedures, methodology and your crisis management techniques to understand if you are managing the show properly or it needs an improvement. Ignoring these will definitely cause more troubles at a later stage.
3. Arguments: Arguments with management, customer, peers, team members etc. do happen during the project. It could be on any matter related to the project. Avoid giving negative statements and mould arguments to some constructive direction where results can be drawn out. A long argument without any fruitful results is a waste of energy.
4. Conflicts: Although a project manager tries to keep everyone in line while driving a project but conflicts are unavoidable. Let conflicts happen but not for the sake of conflicts. Resolve conflicts while taking an in-depth dive into the situation to understand the purpose of the conflict and a way to handle it smartly.
5. Discussions: Discussions and meetings are for the purpose of monitoring of the project. An unexpected situation needs an immediate discussion for resolution. Know the best people to discuss with for your project issues. Unnecessarily discussion of an issue with irrelevant people will not fetch appropriate result.
6. Stress and Strain: Stress and strain need to be managed properly. If you don’t shelve out your stress if will pile up to an extent to reach to breakeven point.
7. Feedback: Seek feedback from appropriate persons concerned to understand your way of managing situations from their angle. It is a good way of building trust among peers, team members and management.
8. Mistakes: Mistakes do happen, risks do occur during projects. Don’t get bogged down. Rather learn from your mistakes and best way is never repeat a mistake. A repeated mistake will point towards your incapability of handling situations. Otherwise you will be quoted as a good risk mitigator.