While standard process and procedures in place by project management committee at most times may overcome any hiccups but at times even a small disruption during project may tend to impede project progress.
During these testing times project committee may feel a need of the revision of existing processes in place so as to revaluate them rigorously to ensure project continuity in such happenings in future. Purpose of review meetings should always focus on strengthening of process and procedures related to project management methodology.
One of the prime purpose of a project review meeting is to ensure that overall progress of project has improved, which can be achieved by participation of maximum number of project stakeholders in such meetings.
Though time is important but equally important is wisely spend of time on important project issues during these meetings. Some burning issues may require extra review and extra spend of time which should not act as a constraint. Every review meeting should act as a catalyst for project and its progress.
Improvement, as wisely said, has no end. Improvement is a continuous process and at any stage of maturity there is always a scope of improvement. When I say maturity, it could be in terms of maturity level of an organization or maturity of your process and procedures for project management. As stated in my previous post, there is no need of panicking in case of any exit of any senior person taking care of project during running of a project.
Though it becomes more crucial if the exit happens at a later stage of a project but if there is some set of standard process and procedures in place, the situation can be managed with a small addition of attention.
During any software project, resignation by a project manager really becomes a regrettable position for whole organization. Someone is immediately required to react towards working to coordinate matters so as to designate his successor as the new project manager (ad-hoc or permanent) at the earliest possible time. No project can afford any discontinuity in its progress.
Irrespective of circumstances, there would be a number of processes running simultaneously in different phases of the ongoing project within same or different teams. The reviews and discussions need to take place on a regular basis under circumstances or even under all circumstances.
The approach of reviewing of project, on a regular basis, need to be carried out in an uninterrupted manner. This is important so that teams working on project do not lose their rhythm and momentum at any point of time. Segregation of tasks that need immediate attention in terms of technical assistance, extra resource, revision in targets, or anything else from the tasks going smoothly with no extra punch required is quite important.
Especially having arisen form such circumstances, there is truly an enormous significance in the process itself in which further directions are decided in view of the running project. This could be achieved through streamlining of running procedures that can be achieved well via smart documentation, regular reviews and proper distribution of responsibilities.
Equal engagement of all team members in project is important so as so is their involvement in reviews rather than discussing about project by a few top chairs behind closed doors.
Prime skill that a business or an organization requires in today’s scenario is a new way of thinking for their existing set of problems. The same thing is terms in many ways – a new way of thinking, an innovative thinking, an out of box thinking, or thinking beyond. Barriers are not set in problems or their solutions, barriers lie in our minds.
The same set of problems if given to different individuals is handled in different ways. This is the same way organizations work too. A project team can also be termed as a mini organization as a sub set of their overall organization.
No individual, no team, and for that sake no organization carry out their operations without facing problems. Recurring problems act as a pain in the neck of any individual, team or organization. It is merely a foolishness to keep getting recurring problems and wasting energies to fight them out again and again.
Energies that should go into new growth charters get consumed into removing the hurdles in path of that growth, which is not a good sign. It becomes daunting for project thereby leading it to a death trap rather than providing it with a spacke to flourish and move towards success flawlessly.
Every organization strives for increase in productivity and profit which is the ultimate goal and a reason of their prime existence. To achieve these two most trusted drivers are better quality and better service to the customer. Sustenance of good quality and good product does not suffice the purpose in today’s business scenario. The word ‘good’ needs to be replaced with ‘better’.
First delivery of a good product or service becomes bare minimum expectation for your customer the next time. Next time delivery of service of product has always to be something extra than the previous delivery in your project.
Every organization has a maturity level. This level defines or controls a level of that organization to acquire a capability of solving problems. No organization at any level of maturity is strong enough to tackle all problems, every organization faces two sets of problems in their agenda – one that are solved immediately for which the organization is capable enough to manage, control and solve; another set of problems is that organization is not able to solve easily.
To manage such ‘not too easy to solve problems’ the organization needs to be innovative, daring and bold enough to carve out new path to find out an optimum solution to such problems. The same applies to each of the teams existing in that organization which further applies to each member of those teams.
Maturity level or capability of solving higher level of problems in an organization is nothing but the collective maturity level of each individual of that organization. After all organization is nothing but a group of teams comprising of individual members.
Merely on the basis of a strong management with high maturity level, an organization cannot boast of having a high maturity level. Every task is not done by the top management but most of it goes further down to an individual level in different teams.
Therefore, the most valuable asset of any organization is the minds of their employees. This is where the role of top management’s role comes into picture – to harness, master, control, drive and empower these individuals.
A lot of juggle has to be an expertise area of any project manager during managing a project. Project without specifications has no meaning. But even if there are well defined specifications which are not adhered to also becomes as meaningless as running a project without specifications.
Specifications are required to be defined for any project. Specifications in terms of project requirements, customer and business needs, team formation, technical requirements, budgets, targets and milestones, and so on. Once these specifications are there in place, they need to be adhered to ethically without any fail or deviation.
Deviations do happen in any project and nothing goes as straight as planned or thought of. There have to be specifications on how to manage those deviations. A proper risk assessment and management has to be in place to manage change, deviations and failures.
This all comes under compliance. What if your customer gets something weirdly different from what he expected from the product you built? How frequently in your project do you face a blush off situation in front of your customer for a large amount of variance in inputs and outputs consistency as compared to the specifications?
Testing coverage specifications is another area that can overcome all these sort of blush off situations. An ad-hoc testing is always a blunder as compared to a well planned testing taking into account the complete coverage of product in question. Testing coverage is nothing but quantification of the areas of system to be tested with how much rigorousness. Serious areas of product having high impact on customer business need to be tested more thoroughly with no scope of leverage.
a perdurable a day, helps you sleep, work and play
Your project dashboard is very important during project management and equally important is its visibility. Purpose of dashboard is not merely for the sake of its existence. Purpose is much more beyond its purpose of merely existence.
Your dashboard must be a report card of your project at each stage of the project. It should be showing metrics of your project performance highlighting the red areas very clearly that need immediate attention. Project dashboard also must have a capability of drawing performance trends – activity wise, individual wise, task wise and team wise.
Take care that your dashboard must update regularly, should run faster, and quicker. It needs to be maintained less expensively with least complexity involved in maintaining and updating it. Don’t forget to have a count of failures on your dashboard.
Technical and functional team’s confidence in any ongoing project depends heavily on their past performance and performance trends in previously closed project and also in the closed tasks of the current project.
A good performance trend in the past always acts as a booster in their morale and confidence at any moment of time. Habit of failures goes less that way thereby mitigating any upcoming risks in a project.
Adopt smart and innovative way of decision making during project management to enhance your team’s capability. Put your team in a position where each team member is dedicated towards a rapid response mechanism. At each step of your project check out the factors that may lead to project interruptions due to any level of functional and performance issues.
To manage your projects across their lifecycles, a project manager needs to learn and adopt a well managed and integrated project, demand and portfolio management methodology.
Is QA, or for that sake QC, an expense or an income for an organization engaged in software development commercially. A step further would be to ask if software development itself is an expense or an income for the same organization. No software is built for charity purposes by any organization for a longer period.
It can be done only in a hypothetical situation for an organization having a regular funding from some other source or another group of the organization. Otherwise an organization having infrastructure and people in place to run a business cannot afford to keep developing software applications without any sales targets with stipulated time frame in mind.
Coming back to our point if QA/ QC costs being incurred for software application development and trying to find out how these expenses are accommodated. To ensure that the right product gets launched in market with least negative impact on organization’s reputation due to application failure, its thorough testing becomes prime goal for any organization prior to its launch in the market. Formidable reputation jerks at a later stage after launch of product in the market cause much severe damage as compared to the expenses incurred well in time to ensure perfect quality of a product before it is launched in the market.
If quality of a product is achieved by any organization for their product to be launched in the market as a signal of obligation to their customers, it is a fake call. It is actually for their own sake that organization spends on ensuring best quality product getting developed in their process of development lifecycle.
Costing of a product must be done accordingly to accommodate expenses incurred on quality of product during development and deployment phases.
A good quality product always brings back hike in reputation of organization and increase in order booking from further new customers. It is overall quality of product that returns back higher organizational income in terms of high volume sales and more orders for their loyal customers. Trust and loyalty go hand in hand. Organizations that are able to build good amount of trust with their customers get their loyalty in return. This all pays in manifold that sometimes goes unnoticed by the organizations.
If there is a choice between mitigation of expense of running Quality department in your software development centre versus risk of service interruptions; later is always carrying a higher amount of risk as compared to former. Spending few extra bucks on quality to ensure an extra amount of product stability is always beneficial over the later stage service interruptions caused by higher volume of bugs getting encountered thereby causing more frustration at customer end.
Let the pain be shared internally before the launch of your software than getting the drums beaten outside by your customer after its launch and deployment.
Well planned initiatives related to achieving higher quality of product during development in an organized manner is always better. This can be achieved well with the help of continuous micro level monitoring and inspection of product during its development to ensure desired integration and quality of product. This will automatically reduce the risk of service and product interruptions at later stage after and during product deployment.
One of the best ways to reduce product downtime is to launch a bug free product. More bug encountered at later stage after product completion and its deployment at customer site will demand large volume of bug fixing, testing, re-testing and down time. This will automatically reduce downtime costs thereby giving a boost to developer and tester productivity.
Proper synchronization among your team resources into a test that enables you to delivers best quality product is always wise to do right from the beginning of project. This will help organization in getting development, testing, and other teams to work together towards a highly reliable product.
In today’s scenario there is no life on this earth without its dependency on any software in one way or the other in professional or personal front. This is what technology and its advancement does, it makes us more dependent on it by providing us more accuracy, comfort and satisfaction. We do something only because we have some trust in it towards the desired results. Same thing happens with our customer also.
When customer buys or orders for a software to us, there is a essence of trust and loyalty hidden behind it in wake of a timely solution that works properly, accurately thereby giving a high level of comfort to customer.
Software that helps customer in getting desired business results definitely increases their satisfaction level. Some points need to be followed while building software for your customer that can be listed as below:
2. It may happen that something unique for the first time is being developed for a specific customer need. But that may not be the case always. In case of horizontal deployment of your software to a new customer, ensure to produce a detailed list of your installation of the same product. Claiming all installations as 100% successful would be something easy to raise customer’s eyebrows. Start with your most successful installations depicting most satisfied customers but do mention some failed installations and their reasons so as to raise an alarm in advance.
3. Ensure to understand your actual efforts involved before submitting a commercial proposal to your customer. Understand customer business and their requirement/ expectations from the software you have to build/ supply very clearly before any getting into any commitments. Ensure about the flexibility limits required in the software as per customer’s expectation. Understand the difference between plasticity and elasticity.
4. Listening to your customer about their business process, pains and expectations is more important than boasting about your product and its capabilities. Before you understand first what customer expects or address to his which business pains, your songs may be irrelevant and may go unheard totally.
5. Demonstrate by way of doing. A well designed presentation about your product and its capabilities may win customer’s hearts but will never be able to run their business and address to their requirements. That can be achieved only by way of software application.
With technology changing every minute, it looks as if we have covered galaxies of distance in last decade or so in terms of advancement in development tools and features. Definitely hardware need to be advanced accordingly to support the resource hungry features built in development tools. Specializations are a defining factor in today’s software development world.
It is not that any development tool will fit in for any software requirement from customer. It requires a complete mapping of hardware, software and peopleware in current scenario to arrive at an optimum solution heading to a win-win situation.
To develop specific software, there need to be a right mix of technical team members. Database administration, database configuration, software development, technical documentation, software testing, software implementation, database and application installation, customer training, customer support and so on are all a mini project in their own spheres.
All these mini projects size up together to build a complete project. All projects are divided into different phases. All phases cannot be started or finished together. Some would be possible to run parallel while others would be sequential in nature. For example software development, server configuration, database configuration, technical documentation can all be started together. While training to customer cannot be imparted without actual software to be implemented at customer site be in place.
Team formation, team coordination, monitoring, follow ups, target setting become prime important to achieve project success and build a strong bonding within teams, with management and with customer.
During different stages of project management, training is an important tool that is used to gain best results of the effort put in project. Be it customer requirements, development, quality, deployment or support; training remains integral part of each phase of project management.
Training contents and appropriate tool/ methodology to be adopted for training depends on various factors such as:
2. depth of subject,
3. knowledge of speaker,
4. volume of audience,
5. time allocated for holding training session,
6. mix of audience
7. and experience of trainer.
There could be many more factors too as per different trainers around the globe.
Methodology to be adopted for a particular training depends on above factors. Various methodologies commonly used in a structured manner for imparting effective training can be listed as below:
2. Lecture: /lecture and presentation are different in the way of more emphasis on speech and by way of writing on his own by trainer during the training on a black or white board to keep his audience alert and interactive.
3. Group Work: This is something like a workshop where learning is done by way of doing in an actual manner.
4. Case Studies: A very non interactive way of training where material is handed over to the trainees to read and learn from there.
5. Feedback Session: This is not actually a complete training methodology but a post training session to gather feedback regarding the training imparted to trainees.
Running a business is nothing but a composition of certain processes in place taking care of all elements important for the purpose of business. Growth of business happens with maturity of processes in place. It does not mean that to run a high level business you required complex processes. Even with the help of simply drawn processes you can establish a high level business. In fact sometimes more complex processes defeat the reason of running a business and become a cause of disaster of business.
To control well defined processes in place, a top level body is called in the organization that is termed as management. Management has to ensure two prime and foremost factors to establish and run a business for long term. First objective is to have well established processes in place and second but more important factor is to ensure those processes being followed all across the board. More control on business processes makes more efficient management; and vice versa. To have good processes in place and to ensure their adherence you need a good management. On the other hand to have a good and efficiently result oriented management you need good processes in place.
Effective and efficient go hand in hand that way. More effective business processes result in more efficient management and organization. More efficient management will always seek more effective business processes taking into consideration some world class benchmarks to set their goals for further optimization. As it is well said – improvement is a never ending process, the same holds truth for business process too. No business process is optimum or 100% efficient. It always has some scope of improvement.
As a new project gets into project initiation phase a formal project strategy is important to bring on board. Team size, team members, financials, operational and all other planning need to be worked out based on project strategy. It clearly signifies that a wrong strategy would lead to wrong direction altogether heading to a big mishap at a later stage.
Team size and team members’ selection is something that needs a very in-depth analysis before finalization of the two sections. This is important because all other factors like capital investments, operational cost and planning etc would depend at large on these two sections.
Although team size and composition changes in between during different phases of a project. But the change is mostly not major one so as to impact highly on initially planned numbers.
Generally organizations that perform at an optimal scale like to analyze multiple scenarios with the help of latest technologies so as to have a smooth ride at a later stage. Different scenarios and their results if analyzed initially help with a quick and rapid change at a later stage with a change in scenario.
For a multiple location implementation in an organization, it is recommended that to do it in a smarter way, an enterprise wide integration planning process right from the beginning would help in a bigger way thereby decreasing start up and deployment costs. An integrated way of planning, budgeting and forecasting helps a lot.
Budget and plan forecasts may be avoided to go haywire at a later stage if uncertainty is removed with the help of latest technologies and large number of scenario modelling.
Total involvement is something which is not visibly tangible but there are ways to do so thereby spearheading any project towards higher rate of success. For example same software being implemented in different organizations has different rate of success. At some place it may be a very successful implementation leading to very high rate of drawing of targeted results while at other place the whole implementation may become a disastrous failure.
Only differentiating factor is ‘total involvement that makes a big difference of success and failure of the same product implementation at two different locations. In between the two – hundred percent success and total failure – lies different success (or failure) rates depending on the degree of ‘total involvement’.
On top of different level of teams in any project management process, there need be a team named as Leadership team on top of all teams. This team may comprise of members from all other teams or may have a different set of members altogether. But the main task of this team remains same – spearheading all others by being fully charged and motivated all the time.
A transparent accountability process also plays a major role during project management during all phases especially implementation phase. Exact deliverables during implementation phase must be clearly defined so as to treat it as a checklist for both teams. Deliverables break down further to micro deliverables that lead to each team’s charter, customer engagement, scorecards, process mapping etc.
Customer feedback is another important tool that not only keeps you aware and alert but also tied up tightly with customer. Just a word of caution here is that never let feedback be too formal or too informal. Let it be realistic and transparent rather than just a formality activity.
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.