Project is dynamic. We cannot manage dynamism in project by keeping our project plan static. Quite often, in organizations and also project managers, prepare a project plan by using requirements just as a ritual at the beginning of the project and keep it as an archived document. They neither update it nor align it as situation and context unfolds in the project.
After all, project is any endeavor of achieving the scope by fulfilling stake holders’ expectations by managing scope and balancing effort-cost-schedule- and quality with the help of resources, methodologies, tools & technology. You can control your ship but not the wind and waves. As a captain, you shall skill to deal with uncertainties and propel to the goal. Never take away your sight from light-house!
Now we shall consider some important aspects managing projects that unfold over time in ways that are often not predictable.
Scope shall Drive your Project but Not Requirements
Requirements of client and users are more often unrealistic. Hence we shall not accept requirements as it is. We have to perform different feasibility analysis, namely, technical, financial, political, and social. By involving relevant stake holders, with the help of collaborative approach it is good to arrive at realistic scope by considering constraints, priorities, and criticalities. Following this, decision shall be taken on scope of the project. Scope shall drive your projects but not unrealistic requirements.
Tailor Your Project Plan based on Situation and Context
In order to fulfill scope, we need to tailor project plan specific to the project, its client, and end-user. While doing so we shall consider client, user, deployment environment, capability, and maturity of the processes of the company. Especially in testing, since we are required to focus on building confidence in end-user and support in producing workable product, scope of testing project goes much beyond requirements by considering competing products, risks, operational environment, localization, and internationalization aspects and so on. We shall consider applicable sub-characteristics from on functionality, efficiency, usability, reliability, portability, maintainability, and manufacturability characteristics.
Refer Fig. 1.4 Common aspects in software testing: characteristics and sub-characteristics and Appendix A in the book “Structured Software Testing- The Discipline of Discovering Software Errors” by Arunkumar Khannur (Page 17, Page 391-396, Published by Partridge, 2014).
Thus we shall arrive at test project plan, by deciding on relevant characteristics, sub-characteristics, and risks and by strategizing based on time, effort, resources with due consideration of priorities and criticalities.
Use Project Plan as Guidance and Never as a Constraint
Project plan shall be a dynamic document that shall throw light on current in-progress activities, whether they are on-time and using defined effort, in case of deviation corrective and preventive actions that need to be initiated along with decisions on continuing on corrections, revisions, rewriting the plan and corresponding criteria for doing so like percentage of effort deviation and percentage of schedule deviation. Also, it is good to notice that project plan shall serve as guidance and never as a constraint. Means we shall continuously update and keep it practical.
Involve Stake Holders Actively but Never as a Process Forced Task
Involving stake holder by using collaborative approach is very crucial. This shall not be a process enforced task where more often we see that instead of product and practice we see people focus on processes and project.
Processes are Good, People are Superior, and Agility is Effective
Use process driven culture and agility as complimentary by creating unique project environment of committed team. No approach is the best. So combining test approaches to create unique working environment is very crucial where extremities of process driven culture on bringing uniformity, consistency, predictability, productivity at the cost of innovation and product focus are overcome by compensating it from practices of agile by saving the project from limitation of agile culture like unpredictability of results and lack of transparency about project progress to senior management.
Use Measurements to Guide but Not as Constraints
Usually testing teams stop as soon as defined measurements are satisfied. This is not right. It is good to use measurements and statistics as guidance but not as constraints. It is not right to stop as soon as defined measurements are satisfied but to depend on other things like looking at trend of bugs across testing rounds, number of open bugs, views of other stake holders on release and so on.
Set Expectations and Invest in Training
It is good to initiate testing project by setting expectations, taking commitments, and defining inspiring name for the testing project by involving and brainstorming in testing team. Also, training is an investment. So it is good to invest in training to build knowledge on product, process, domain, and classification of bugs.
Focus on Balancing but Not on Perfection
Aiming at perfection is always disastrous since requirements of stake holders are conflicting. Hence fulfilling these conflicting requirements of stake holder will result in issues and concerns. So focus on balancing by creating give and take culture with clear cut objective of delivering good product by balancing scope-effort-cost-schedule-quality-and risks.
Passion Shall Prevail over Your Pride
Pride of a particular stake holder quite often with no knowledge to them is getting converted into ego clashes in a testing project. Testing team focuses on bugs, development team on fixing of bugs, design team focuses only on design with no inputs to testing team, and so on. All will exhibit accountability and ownership on their role but not on their contributions to product success, customer and end-user satisfaction. Inter-dependence is preferred over autonomy. Also, it is good to make all stakeholders to know that how their contribution and collaboration will result in product success. In addition to this building culture which speaks in practice that all will work with a single focus of delivering product with client and end-user to make them happy and confident is more crucial. Building this culture is very challenging and at the same time very entertaining.
Align by Keeping the End in Mind and Have Moving Goals
When all stake holders keep the end of the project in mind and work as a spirited team to achieve it through inter-dependence then progress will be fast. Team starts reaching goals ahead of time, also, if team is totally at disarray with blame game at full swing then there is always a missing targets. So to keep expectations to fulfill SMART objectives, we need to move goals so as to keep project specific plan relevant and practical.
Learn, Correct, and Proceed
Failures are opportunities to stop and think. We shall learn from them across project, correct and proceed. In most cases, projects fail because of failure of people but not because of failure often technology or process.
Never Loose Optimism and Self-Motivation
Project may be getting delayed, key people may be moving out of the project, requirements may be ever changing and so on. Under any circumstance never lose optimism. Take such things as challenging, challenge yourselves, believe in your strengths, and get self-motivated. Loose anything but never your optimism. Bad time, bad situation will be getting replaced by good time and good situation if you address situations with optimism, self-motivation, and self-belief.
Trust but Never Make any one Indispensable
Trust your team members but at the same time never make anyone indispensable. Inter-dependency is preferred but over dependency is disastrous. Have or create back-ups for every critical role.
Be Practical and Take Challenges, Ready to Accept Change!
Be practical. Accept changes as they come since you cannot avoid them in these customer-centric and end-user centric days. Use practices of agile and develop strategies like continuous integration by scoping & testing in small chunks. You really love it.
Make Project Management as a Strategic Endeavour but not as a Plan Driven Dry Run
Plan is good to have to get useful information on available time, available effort, and expected deliverables. However plan will not get into reality unless we develop coping capabilities by using strategies to make it dynamic by providing proper technical and process related direction so as to continuously align it to practical situations.
Defer Judgment till the Completion of Root Cause Analysis
When something is wrong never be judgmental but wait till the completion of root cause analysis. Good root cause analysis with “how to” approach with logical tree is preferred over “what” approach. Use it. For details, refer the book “The Mind of the Strategist” authored by Kenichi Ohmae,
Share your Practice
Never keep the practice but share it as professional responsibility with other teams, organization, and if possible with practicing community.
When you use these practices which I learnt over years, I am sure you enjoy your project.
I look forward for your views. Please send to firstname.lastname@example.org.
Also visit www.khannur.com and www.isqtinternational.com