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.
Let us look at a practical scenario. A project manager of a mid-sized company (under its expansion plan) is given a responsibility to manage the hardware requirements of its new team at a new location. The new team is to be recruited and each team members is to be provided with a sufficiently working laptop. The project manager has to decide on various factors for the hardware requirements of his new team and many ideas bubble out in mind, like:
1. What to buy?: The technology is changing everyday. Today’s hardware purchase becomes obsolete at a very fast pace. Average hardware life in decreasing in today’s price versus technology war. If the procurement process takes long in terms of time in any organization, the final decision of buying a piece of hardware could result in procurement of an outdated product. Decide on the minimum requirements of the software to be run on the machine and based on that arrive at the configuration keeping a buffer of memory, hard disk, processor, graphics in mind. Software to be loaded on the machine too has its end of life predetermined by the software provider. So be sure about the hardware requirements of the software tools, OS etc. that are to be loaded on the machine.
2. How much warranty to be bundled with the purchase?: These days hardware comes with a tailor made warranty plans. Besides standard warranty of the product you can have extended warranty for different periods by paying its corresponding warranty cost. Bundle this cost with the initial cost of the product and you get the extended warranty for a period of 3 years, 5 years and so on right from the day one of your purchase.
3. Purchase Service contract on equipment and replace computers every three (or less or more) years: With the trend of technology enhancement every other day, your newly bought latest piece of hardware becomes short of certain new features shortly after the purchase. It is recommended that in such scenario have a company wide policy to replace your current hardware after every stipulated number of years. For example a policy of replacing all desktops and laptops every 3 years is not an unknown phenomenon these days.
4. The manufacturer provides a warranty on electronic equipment. Further protection is a rip-off: The warranty on your hardware does not suffice the purpose unless it is equipped with the equivalent warranty/ upgradation plan of other supporting agents. Anti virus, anti spam, firewall policies, network policies etc. all are non-isolated entities and need to be considered for each and every piece of hardware residing in a company. Some individual machines may require customized policies or features.
5. Rent electronics rather than purchasing them since technology changes so quickly: In fact the hardware can be leased on a service contract consisting of replacement terms and conditions as part of the contract. If the equipment is procured on rent, it becomes prime responsibility of the equipment provider to keep it defect free, 100% uptime availability and regular upgradation plan.
6. Create a common workspace where people sign-up to use machines. Limit use to two hours windows so that everyone has equal opportunity access: This is another practical scenario in heavy people centric organization where people can be called in shifts using the same set of machines in their shift being used by another set of persons in the previous shift. No machine belongs to an individual but an individual gets a feel of using his own personal machine by logging in with his/her own credentials.
The same solution may not work for all, as it will depend on nature of work of the company, its number of employees, its culture, policies and certain other parameters.
There are two options to focus upon during your project. Either Focus on results without bothering on the activities going on during the different phases of your project. Or focus on the activities of your teams without bothering about the results.
When you focus only on activities, apparently it would appear that all will go well since you are examining each and every activity under a microscope. Any loophole or defect in a particular activity will immediately pop up with an alert for the team to seek improvement or enhancement in that process thereby yielding an expected and desired result. With an eye on each activity process and fielding improvements where required will optimize each activity resulting in expected results in the overall project.
When you focus only on results, each team is supposed to produce results without much bothering about the activities they perform or the process they adhere to. The timely results will speak out loudly about the right processes in place and right activities being performed. A successful achievement of results at each stage of the project will finally produce a thoroughly successful project at the end.
Certain points to ponder upon could be:
1. When we talk of first case where prime focus is only on the activities – Is it possible to find out a slack or defect in a process without looking at results? A minute monitoring of activity or process if yields the desired result will automatically fall in a category where not much attention is required to enhance it. But even if a minutely observed activity or process if does not produce desired results will definitely mean that there is something wrong in the process or the activity being performed and requires immediate attention.
2. If you just keep focusing on results and you keep getting useful results, you might not bother yourself or your team to look deeply into the process adopted or the activities performed. A continuous yield of good results will take away attention from the process or activity monitoring which could result into a hot lava increasing under a volcano. The volcano can burst anytime at a lager stage resulting into a disaster.
That means a middle path is required to be taken where an examination of process, activity and result go hand in hand. This middle path will be most suitable for a sustained fruitful result and for any form of short term and long term benefits in the project.
Any product development requires extensive testing process before it is launched for production. A great effort is put by the software development company to launch the product for its customer in its perfect working condition. The goal is to provide the customer with an equivalent volume of benefit of the product in lieu of the price paid by the customer for it. Though all stages are crucial in product development lifecycle but utmost care is required during testing phase to ensure that there is utmost alignment between the product specifications, customer requirements, customer expectations, product developed and product delivered. Any gap will reap unwanted and harmful results.
There is always a gap between the perception of customer about the product and the actual product delivered. This is revealed only during the delivery phase when customer gets the first exposure of the real product. Product manager and development manager take definite steps to ensure that customer encounters least surprises at the time of delivery of the product. For that, it is always recommended to involve customer’s key users and management during all phases of the project. It is the duty of project manager to keep customer front updated on each and every step towards the progress of the project.
It is the customer finally who is going to vet whether the progress perceived by the project manager is PROGRESS in reality or if there is any gap. The customer’s observations need to be captured and recorded as clearly as possible to understand this gap, if any. Otherwise if the product is developed in closed doors without customer involvement, it could give a shock at the time of the product being brought out in the light for the first time.
The responsibility of project manager does not end by ensuring that all information related to product development reach customer front, he also need to ensure that the customer feedback at each step is taken seriously and followed upon. Any discrepancy of non possibility of adherence to any point or requirement highlighted by the customer should also be updated to the customer with a valid reason.
It is better always to demonstrate the partly produced software at frequent intervals to the customer in order to ensure that all people involved in the journey are sailing on the same boat.
A product manager during the product lifecycle has various options of selecting a pair of shoes to wear. It depends on his choice whether he wants to cover the journey in comfort and feel the pinch later or wears a not-so-comfortable pair of shoes felling for a pinch during the journey but feeling relaxed at the completion of the journey.
The various choices of selecting shoes are:
1. Shoes of his top management
2. Shoes of an analyst
3. Shoes of a technical architecture
4. Shoes of a developer
5. Shoes of a programmer
6. Shoes of a tester
7. Shoes of a development/product manager
8. Shoes of customer key user
9. Shoes of customer management
10. Shoes of Support executive
The choice is purely yours now as a development or product manager which pair of shoes would you like to wear. It also depends if you wear the same set of shoes throughout the journey or change it during the different stations of the journey depending on the current path of your journey. But keeping all shoes handy and an attitude to readily change the shoes will definitely keep your life less stressful.
Obviously you need to perceive the right moment to change your shoes, as wearing a wrong pair of shoes at a wrong time would give you more pains at that moment and moments coming at later stages.
Check out – which pair of shoes are you wearing at the moment!
And remember one more thing, if you don’t have the right pair of shoes with you to wear at right moment, lend it, but don’t run without it!!
When it comes to product building, a product manager is the person who is whole sole responsible person to own its success or failures, whatever the outcome results into. The product manager needs to carry some hot properties in his kitty to win over the situation.
His kitty bag should contain:
1. Good Business knowledge: Without an ample number of years of experience nobody can become a good product manager even with very high skills and qualification tags. A person who himself has spent certain substantial amount of time in understanding business, developing product and maintaining quality in his early career stages cannot become a good product manager.
2. Business analysis skills: Though this job is usually done by someone else in project management but a product manager is supposed to have an equally balanced business analysis skills to overcome any of the customer requirements skipped or semi-understood by the business analysts before the product development starts.
3. Technical know-how: Without having a good technical knowledge a product manager cannot decide about the right platform, development tools (front-end or backend) and thus his decisions about the technical set-up may create a big problem at a later stage.
4. Team management: A team comprises of all kind of people. No two programmers or testers think the same way. Two programmers will write the same code requirement in different fashion. The code written in two different ways may perform same but the two codes written may differ in terms of complexity, structured designing and size of the code. Similarly two different testers will test a code differently and will bring out different results. These issues at stretch can me managed with standard procedures. But there are more issues related to team – HR, behaviour, attitude, knowledge, experience etc.
5. Business solution architecture skills: A product manager has to be visionary in deciding about the product architecture. Database design, table structures, code architecture guidelines, server sizing, etc. has to be dealt with keeping in mind that these things create complex issues if require a change at a later stage.
6. Time management: Product deliver commitment is done in two ways. One way is estimate each micro level activity involved in the product development and then commits a deadline for delivery of the product. Another way is just give an estimated deadline and then start reverse engineering to fix timeline for each micro level activity. A buffer time basket will definitely help in both the cases to manage unpredicted problems arising in between during the development.
7. Leadership: There is a different in commanding the team and getting the things done by demonstrating yourself. The product manager has to lead in certain cases to demonstrate the team various possibilities in managing the situations.
8. Managerial skills: A regular flow of monitoring, follow-ups, sanctions, approvals, queries, questions, issues, confusions needs to be managed to keep the team members tied in a rope together to drive on the same road together in the same vehicle to the same destination.
9. Communication: A three way communication is very essential for the product manager during the product development. He needs to keep the communication bar intact and aligned between the customer, his own management, and his team members. He should be very clear to identify between the information that needs to be shared or to be communicated without sharing with others.
10. Change Management: Change requirements happen anywhere and everywhere even in day-to-day life. During product development, many such requirements arise that need to be managed tactfully and smartly so that the progress doesn’t get hampered on one hand, and the momentum of the team stays up-swing always.
11. Disaster Management: Risks are bound with any development be it a personal life relationship or a product development. A product manager must always be prepared for pre-conceived or sudden unknown surprise risks. He must be able to get the crux of the situation at any such moment and move ahead with a timely taken right decision.
If the product manager masters on the above skills and his delivery model accordingly, he has all chances to win over the situation by delivering the right product to his customer in stipulated time-frame.
Imagine yourself as a commercial builder. You are contracted for building a multi-storeyed building by the owner of that plot. The owner is too busy to concentrate on the job himself. He finds you as an expert in this line. The conceptualized model has been described to you by the owner. You are being paid to get this concept into reality. Owner does not want you to bother him again and again for understanding the requirement or building a right product.
Understanding the requirement and building a right product are two separate entities. You might have understood well about the requirements specified by the owner to you. But fact is that you are not going to build it on your own. You will hire a group of teams to perform this task. The dream concept, of the owner of the building, need to be translated well to the actual labour, who are going to build it. You have to be as equally good strong imagination power as able to explain it well to the people who are going to build it.
The owner perceives that his job is over by telling you the requirement and paying you a handsome amount to you to handover the responsibility to build it as per his dream. How much of the built product you are able to convince your owner depends totally on you. Nobody else is going to help you in that. It is purely your call that even if you build purely as per his requirement, he may not like it. It is your risk. You have to manage it and win over these hurdles. All labour and other people engaged in building process are directly under you and not under the owner of the building. You have to manage them, you have to pay them, you have to get the right product built by them to satisfy your owner.
The same thing applies in building a software product. You engage your customer during the build or not is your wish. You may be 100% confident that you have fully understood the requirement and are building a right product without involving the customer during the various stages. You could be confident in understanding the requirements and building of product but still may involve customer during all major stages of the project and keep taking his approval. You might fail in both the cases in final leap but chances are more if customer is not engaged during your journey.
A testing career like any other careers in Software Project has a long journey to cover to reach to a level of satisfaction. Tester needs to perform his career objectives consistently during all stages of his career. A consistency in performance will help him sustain his current level, but to acquire a continuous growth plan, he needs to think differently. A continuous improvement plan is required to attain an upward graph in his career growth. An extra edge over his peers can be attained by adopting following qualities that not only help in career growth but also provide a strong belief in his capabilities.
The qualities can be listed as below:
1. Capabilities Assessment: A Tester needs to assess his current capabilities at regular intervals. A regular monitoring helps him in analyzing the capabilities growth chart trend. If his capabilities increase continuously, the trust on him by his peers will keep increasing. His seniors also will rely more on him for any new challenges that come across during different phases of project related to quality areas. A regular trend also helps him in ascertaining his future capabilities.
2. Optimization: How do you optimize your skills? Do you have a successful mandate for that? Do you realize the importance of that? Do you understand the benefits of that? All these questions will definitely prompt you to understand the importance of optimization of your skills. It not only helps you in your professional growth but also enhances your knowledge stream thereby providing you an internal satisfaction. The catalytic effect is enormous in assessing your potential once you start driving on this path. The best way to get the feel of it is through your peers, mentors, seniors and friends.
3. Sustenance: Achieving a height is simple as compared to sustaining it. Next heights can be achieved only once you sustain your current potential. Then you can strive for your next leap. Higher level of capabilities can be tapped only by way of achieving it and more importantly sustaining it.
4. Strategize: There are two ways of growing. One is choosing a smooth road and driving on it without much efforts and pains. Another way is to choose a road with lot of potholes, doing extra efforts, taking pains and making your drive a smooth drive. If you want to catch sight of your peers and managers, choose the second path to demonstrate your hidden skills and talent. The managers will not hesitate in empowering you once you win their trust once for all.
5. Neutral: You need to take a neutral stride. Unbiased opinions and working style pays in long run. There is no short cut to success is a well known saying. Repeat it everyday so that it gets engrossed in your mind. Be open, neutral and transparent in your work.
Project Management is not everything related to the management of a project. It is absolutely not the end of the road. If you have a well defined project management methodology (or different methodologies for different project types actually), it never means that just the regular reviews of these methodologies will make your project’s life smooth. Project management and organization continuously need to think beyond the horizon of project management to look into the galaxy and keep exploring the new innovative ways to enhancement in the existing processes and methodologies.
The success of project depends on an absolute success of each of its phase which further is divided into that phase’s milestones. The adherence to timeline and budgetary targets need to be adhered to in order to achieve success in any project. Project management though comprises of different phases starting from project initiation till the project implementation, handover and final sign-off, requires different skill sets to mange each of the project phase.
If we look at the major areas that are required to be managed in a systematic and specialized manner, those would be:
1. Requirement Management: This is most critical phase of the project requiring specialized business analysts having a strong visionary knowledge about the business, product and documentation. Lack in any of these skills would impact on the total flow of the project lifecycle.
2. Development Management: It requires a good combination of skill management, team management, time management, task management and talent management. The development manager need to be a master of all these skills to get an edge over the timely delivery of the product.
3. Test Management: Test management requires an altogether different skill set. The test manager need to be proactive, innovative, intuitive with a good knowledge of the business and product.
4. Issue Management: No project progresses without any issues. A systematic approach to manage an issue helps in managing the project in a better manner.
5. Change Management: Changes to happen during a project, change in team, change in deadlines, change in product requirements, change in management perspective, change in strategies, change in plans and so on. A proper well defined change management process helps in managing the change smoothly.
Without a vision, project can never be managed. Without management a project has all chances to go out of control. To have full control over the project during all its phases certain visionary tools are required to overcome obstacles. Different teams are engaged during different phases of the project. Many teams have to be vertically and horizontally coordinate to make each phase a success to jump over to next phase. Certain phases overlap during the project lifecycle.
The teams harmony and coordination (inter and intra) are the two most useful keys. Team members are responsible for their individual roles. But they need to rely on their peers across other teams to progress. Project success, on top of all other motives, has to be supreme and universally acceptable to all teams. Stakeholders and top managers play a major role in achieving these goals.
Some important visionary tools in that regard, can be listed as below, which if adhered to in right manner, help in achieving the desired results at all stages and thereby providing a grand success to any project. Irrespective of project methodology or processes adopted in project management, these tools act as catalysts. The tools listed below need to be adopted and absorbed in all teams across the project board. The tools are:
1. Purpose Clarity: Project purpose must be very clearly defined right in the beginning of the project. Without a clear cut purpose, corresponding goals can’t be set. And without goals, no objectives can be achieved.
2. Vision Sharing: Top management and stakeholders have their own vision for any software project. The business goals and organization processes to be controlled through this project (software) must be clearly defined. The short term and long term vision must be shared with all the teams involved in the project.
3. Clear Responsibility: Purpose, goals, vision, targets etc. are important, and equally important is to clearly definition of responsibilities. Ambiguous or unclear responsibilities may lead to lot of confusions and ultimately a big disaster.
4. Mutual Harmony: A team comprises of different individuals having personal perspectives and ideas. A clear vision, purpose, set of goals, responsibilities keep all team members attuned and attached to each other like a bunch of flowers. Sharing of individual strengths by means of complimenting and supplementing will lead to a good harmony and thereby guaranteeing a project success.
5. Trust: Different teams need to trust each other. A vertical and horizontal scale of trust built among various team members within a team, and various teams brings better results. Positive conflicts do occur within or across the teams but as long as they are combined with mutual goals of targeting a powerful goal achieving plan, it benefits the project.
6. Feedback and Sharing: Isolation never pays good results. A continuous feedback is important by different managers to their team members. For feedback, managers need to be in line with the happenings around them. A regular review process, feedback and sharing of ideas gives a boost to the project progress.
A project never goes smooth. It brings unexpected problems during the execution of any phase that marks a difference between the planned activities and actual executions. The deviations enforce re-planning of further activities so that the extra budget and time spent on previous activities can be compensated by revised project plan.
A loser is a loser only when he realizes it and gives up. As long as one thinks he has the capability of changing lose situation to a winning situation, he is never a loser.
Project management philosophy emphasizes on sharing the problems with all stakeholders and team members so that different brains come out with different responses and any of the response(s) can become the best solution(s). Challenge sharing definitely brings out a solution from somebody else having a different set of experience and exposure who has already been into such a situation and has come out of it already. Sharing problems and challenges saves one from re-inventing the wheel. Documentation sharing and a knowledge sharing platform make a strong basis for keeping all on the same wheel.
Managers mostly focus on driving out results from the teams rather than enabling and empowering them to become self driven. Energy flows automatically and uncontrolled. Results start coming out without reaching the deadlines and prior to demand. It depends on managers that by empowerment they start preparing or building leaders within the teams. A combination of leaders, if synergized properly, propels a resultant progress of the project.
Managers become critical key in engaging people in the project. A high level of engagement is lodged in the team members via project manager. As long as the project manager is able to drive teams, it makes them engaged to the project. On the other hand if project manager inculcates and inspires team members to self-engage themselves, the team members do not depend to be driven by project manager.
Both accept challenges. Both have an ability to drive the situation. Both have knowledge and experience to handle a deadlock. What varies is their style of thinking and working. A project manager and a project leader both have a mixed blend of all qualities. What varies is the way they manage a problem.
A leader can be a manager and a manager can be a leader at times. Situations arise when a leader has to manage and a manager has to lead. When a leader is managing a situation, he might be acting more like a manager. Similarly when all of a sudden an unplanned issue arises, serious in nature, and needs an immediate solution, a manager might have to lead others in demonstrating how to manage such situations without looking for standards and procedures. The manager in such situations uses intuitive and innovative techniques more found in a leader.
Most of the successful managers and leaders are good thinkers and have strong expressive powers. Some basic differences between a leader and manager are:
1. Leaders have a power of changing the world. Managers have the power to manage the change.
2. Leaders find out the innovative ways, managers find out the best out of them to adopt.
3. Leaders are the frontrunners leading the way, paving the way, carving the fortune. Managers stay behind the team, taking care of each of the member, managing, monitoring, planning and executing.
4. Leader is more like a mentor; manager is more like an organizer and planner.
5. Leader looks for new challenges, manager becomes an expert in finding out best solutions when encounters a new challenge.
6. Leader enjoys panicky situations. Manager avoids panicky situations.
7. Leader is more like a revolutionary, manager is like a strategist.
8. Leader knows how to convince others with new ideas, manager adopts best procedures to convince.
9. Leader showers credit on team, manager takes the credit for each success.
10. Leader makes teams capable of handling adverse situations by empowering them, manager facilitates teams to achieve targets.
A tester must be visible to the test manager most of the time. The visibility comes through many ways. By means of communication – verbal, mail, status updation, discussions etc. Visibility helps a tester in many ways.
Some of the benefits to the tester by keeping himself visible could be:
2. A constant touch with his boss and other team members,
3. An informal feedback from his peers and superiors,
4. An update on the expectation level of his manager,
5. An positive image of a hard/ smart working person,
6. Challenge acceptor,
7. Trust and respect from his manager,
8. An improvised personality,
An invisible tester on the other hand will never be able to emerge as a winner in above aspects though he/she might be doing better in performance than others.
So the crux of the matter is:
2. If you don’t work, you can’t show it, as nothing is there to show.
3. If you are good in show business, you can grow better than others even if you are doing less.
4. If you are good at work, and good at showing it – you are an ultimate winner.
5. If you are doing nothing and trying to show a lot – you are going to be an ultimate loser.
Broadly a project manager and a project leader seem to carry a similar profile – that is of managing a project and leading it to success in stipulated time period. But if we seek a distinct clarification between the two roles – there comes a demand of a wide gap – as wide as 180 degrees. If one is a creator, another is a builder. If one is a sprinter, another is a marathon runner. If one is a swimmer, another is a flyer. if one is a dreamer, another is a doer. If one is a magician, another is a daredevil.
A manager is supposed to manage his project efficiently. Without taking much risk to avoid deviations from his project plans and milestone deadlines, a project manager would prefer to drive on a smooth road having least speed-breakers and potholes. The best team members, most comfortable deadlines, least cumbersome coding is what he would strive for. With a consistent manner of thinking, a project manager would prefer to strengthen himself and his teams with least changes during his project lifecycle management.
A project leader is supposed to be an innovator. He would be finding out new ways of performing a task rather than following the legacy or orthodox methodologies. He would be a person demonstrating ‘walk the talk’ rather than sitting on a chair and demanding the results. A project leader would not mind if things are not managed very efficiently as long as the desired results are coming upfront. Consistency is not a mandate for a leader. He would rather call for inconsistency and higher risk as he has an expertise to manage those situations.
1. No problem is small.
2. Never look for Shortcuts.
3. Never Jump to Solutions.
4. It is not true that a larger problem will have a higher risk.
5. Seek for value addition in any task you perform.
6. Build a culture around the teams.
7. First See and then Solve the Problem.
8. The gap between the Scope of Work and Scope of Control build up your Risk.
9. Learn Simple but Standardized Problem Solving Methods.
10. After you complete a task spend some time to analyze if it was worth that much time spending on it.
11. Time difference between resolving a problem and figuring out the solution should be minimal.
12. Attempt a solution only when you are clear about it. Hit and Trial method does not pay in most cases.
13. Learn from each problem.
14. Never Repeat a Problem.
15. Share Problems and Solutions.
16. Keep Project related Communication as Structured as possible.
17. Demonstrate others the ways to solve problems.
18. Collaborate People.
19. Don’t spread dirt if you intend to clean the mattress.
20. Still water is more prone to getting Stale.
Regression Testing takes lot hell of time out of overall time provided for testing of a product in any software project. Though it takes longest duration for complete product coverage but somehow or the other lot of things remain untouched or unnoticed during this testing. This could be due to lack of experience of tester, lack of knowledge of product, incomplete or unclear product/ business/ development documents or shortage of time and own management/ customer pressure. Each of these factors marks a big impact on the presumed smooth road of project journey.
Lack of knowledge of the tester could cover up in short form of testing but will definitely leak out in the larger version of testing i.e. regression testing. Many testers worldwide still feel regression testing as most boring and sometimes as non-productive too. Even the development teams feel prolonged time consumed for regression testing by testers as an un-necessary exercise. Due to its long duration many times the momentum and tempo of the testing team goes low. Test automation could be a solution in such situations to shorten the duration of testing and to cover up other shortcomings.
Product knowledge improperly transferred to tester could lead to an erroneous regression testing. Business knowledge transfer by respective business process owners at customer end to the business analysts could lead to another disaster of ambiguous documentation giving a totally wrong direction to product development. Right and appropriate business knowledge transformation is very important.
Larger chunk of total project time allocated to development thereby left with a shorter time-span for testing is responsible for dissatisfied customers.
To sum up the whole gamut, regression testing being the most difficult and crucial phase of project management should be justifiably have a strong backup of development team, customer management, own management, project manager in terms of providing the testers with accurate documents, product knowledge, sufficient time, and above all a good morale support.
Delivery Process: Delivery rate and delivery volume is directly proportional to productivity of various teams. Delivery of product depends on rate of development and testing, delivery of implementation depends on speed of implementation and so on. A process for delivery will focus on streamlining and enhancing productivity at all stages of the project. A collaborative and synchronized productivity will impact more on project delivery rather than focusing on a particular phase of a project. A delivery process also takes care of course of action in case of intermittent team size variance, multi location complexities, technological issues, defect management, test management, time management etc.
Empowerment: Never build an atmosphere of too many restrictions. Discipline and empowerment if imbibed in each team member, require no restrictions and process delaying approvals. Be more delivery oriented rather than restricting your team members to report in time. Flexibility in time can boost teams to deliver speedily.
Governance: Governance and Empowerment can go hand in hand. Governance of process, procedure, methodology, metrics etc. gives you better control over the project.
Optimization: Never compromise in terms of architecture, methods, tools, development platform, project organization, team structure, team sizing, infrastructure and relevant constraints to product a sub-standard product. It is better not to put half hearted efforts than producing a half cooked product.
Traceability: If process, methods, tools, teams and metrics are in place, traceability is important to understand the optimization level of each of them. No traceability means no tracking of output, result, progress etc.
Modernization: Building a product on old version of software or using non-current infrastructure could lead to a no-support scenario in a short run. Technology is changing very fast. Build your product using latest technology, get your teams skilled on them fast, and build product taking care of technology in news and about to come in near future.
Lack of communication, during any Project, forces team members to assume. This happens due to lack of clarification and shortage of time. The product built on assumptions stands nowhere for a useful purpose. Assumptions in turn create confusions and confusions lead to disaster.
A small assumption made at any step of the project may cause a severe negative impact on Project, Product and Managements involved. Data when validated becomes information which forms a basis for building a code. An assumption made in group or by an individual in isolation is bound to result in ambiguities. If for some purpose some assumptions have been made, then it needs to be validated with the help of a complete description and may be if possible, with an example. Example cited with a description give more clarity to the person who has to vet the case.
Assumptions result from not at all/ unclear/ vague communication. The sender and recipient of communication, both are at fault, if the communication loop is not closed properly. Any communication should be done with no pre-conceived notions in mind either by sender while sending it or by receiver at the time of receiving it.
Making assumptions is not bad. We do make assumptions many times a day. But those assumptions do not affect us badly. For example on a crowded station, I may make an assumption while coming back from office that first train might be missed due to heavy crowd. It does not affect me heavily even if I am able to catch first train amidst heavy rush. The stakeholders involved in this case are very limited – me and my family. But when it is a question of a business proposal involving many teams, stakeholders, project, product etc., we cannot work on assumptions. A realistic approach which is more objective and measurable is necessary in such scenario.
Assumptions made during project may cause misunderstandings, conflicts and confusions. Even sometimes an improper/ incomplete communication is the cause for this.
A structured communication process needs to be in place in any project management.
As discussed in previous post Identifying Hiccups During Project Lifecycle the identification of the showstoppers or hiccups in a project is very crucial. An appropriate action on a problem can be taken only if the problem is identified correctly. Otherwise the wrong identification may lead to a wrong analysis and solution thereby changing the direction of the project in an uncontrolled direction.
Some of the most crucial hiccups in a running project could be summed up as below:
1. Collaboration: The teams and stakeholders need to collaborate and be on a single platform to catch the same train. Else they would be travelling in different directions nullifying each other’s distances covered. The net effect in that case could lead to nil or negative.
2. Communication: Formal communication is an integral component of a successful project. Lot of communication going in an informal or unstructured manner could lead to ambiguities and confusions thereby resulting in chaos.
3. Team Building: Each team comprising of right mix of candidates is mandatory to achieve optimum results. Too many cooks may cause lot of conflicts.
4. Leadership: Right mix of empowerment and leadership is very important to run a project.
5. Service: Project development is a mix of service and product delivery. The service part is generally over-looked as the major focus is kept on product. The interruptions in service could lead to derailing of a smoothly running project.
6. Time-Plan: Adherence to time-plan during each stage of project is very crucial. A prolonged delay in project sometimes leads to complete rejection of the project if a need of technology change arises due to delay.
7. Language: Language barrier is a big risk in most of the overseas project. It has to be handled carefully otherwise there would be a big gap in understanding of the words being told and their perception in understanding.
8. Control: A control of down-time in hardware, code, people could lead to a big disaster. Cost also needs to be controlled.
9. Quality: Focus on quality of not only product but process, people, plan and code also plays a major role in project.
10. Integration: Integration of teams, management, stakeholders, code, modules, and product – everything is important.
A project of any nature or size, demands collaborative and systematic approach, from all teams, stakeholders. The teams engaged in various activities and tasks need to tackle hiccups and abruptions arising out of any internal or external turmoil.
The time-bound projects, if not finished in time, may cause issues raised out of business continuity, stakeholders or team member’s exits, technology in use going outdated, or change in management’s outlook causing decision changes.
The emphasis on cost reduction, restricted team size, productivity increase, control on expenses, process enhancement, collaboration optimization, quality improvements etc. are the factors that create pressure on the teams working on the project and in turn may affect the progress of the project. These factors need to be managed tactfully and smartly. If not, then a single pressure may cause aggravated impact on the speed of the project. A systematic approach becomes paramount in such cases to cross the fire safely.
If systems and processes are not in place to manage each and every phase of a project, it leads to panic across the teams. The smooth sailing gets disturbed thereby causing turbulence and unnecessary hindrance. It may call for a re-organization of the project organization in extreme eventuality even. To avoid such extremities, a better decision making approach, improved information structure and clear cut role definition becomes very crucial.