while there is a section of organizations, developers and project managers who have built a large amount of trust in Agile Methodology, there is another section of the same set of people who challenge Agile methodology, its unrealistic & unstructured process; and its most cumbersome part – governance. As per the critics of Agile methodology, governance of the practices is a big challenge; and they put valid reasons to vet their version. While the success and failure can’t totally put the credit or blame for this on Agile methodology for the same kind of projects running in two similar kind of organizations leading to just the reverse fates.
There are a large number of organizations who have adopted Agile methodology and have been able to drive and govern it successfully. The reason for this success as per the pro’s is given to the right adoption of methodology and framework whereby the basic principles of self assurance, self discipline, right adoption of practices lead to good amount of governance and self accountability on its own emerging out of self ownership of success. It is widely evident that Agile methodology is always in continuum and highly collaborative. This dynamism is always a bi-directional tool for gaining success. On one hand it provides quick and visible results and on the other hand it demands a regular review of deliverables. With such quick reviews, any hiccup in the path of success is tackled with an alternative action plan.
Such kind of collaboration provides quicker results, instant identification of problem/risk and its faster resolution.
In my just concluded post I tried to highlight the basic difference between traditional project management and project management with Agile methodology. The emphasis remains on harnessing over the biggest hurdle in any project which is ‘unpredictability’. This unpredictability can happen in any shape – customer, task, resource, team member, management, PMO, or any other stakeholder. It is not that Agile removes unpredictability. What it does is that it provides a methodology to adopt to reduce unpredictability drastically thereby improving chances of success.
When you have a higher level of predictability available with you with the help of insight or foresightedness you will be able to act in a proactive manner to build a stronger strategy to overcome risks. Agile methodology helps you in building smaller task cycles and thus embedding them with clear cut results of deliverables. All this happens in shape of iterations. Agile methodology emphasizes on incremental (or iterative) progress rather than the legacy waterfall approach in traditional project management. We all know that in waterfall approach, project teams have lesser chances of getting things ‘first time right’, specially in development. In Agile methodology, unlike traditional project management approaches, each aspect of project is revisited and realigned. In first go it might appear to be a more time consuming approach. But if you see the amount of energies and time required for exact alignment is always lesser as compared to the risk of derailment at a later stage.
When each aspect of a project – customer requirements, development plan, development etc. are visited frequently with a target of focusing more on the alignment among all, it provides a firm base to the project teams to move ahead in the right direction assisting them in achieving their goals within stipulated time frames.
If comparison is done on the basis of success rate between the traditional orthodox project management and project management with Agile methodology, it is more than 50% of gap between the two, worldwide. What it means is that when you adopt agile methodology to manage your software project, your chances of winning the game increase because the methodology itself drives you in such a manner so as to enable you and your teams to get geared to achieve your milestones in a timely manner. What was happening earlier when Agile was not introduced in project management was that the failure rate was pretty higher and on top of it the reasons for failure used to be so prominent and powerful that a firm belief used to build up to accept these failures with open arms.
Gradually companies and corporate world started realizing that acceptance will do no good to both ends. Some transformation was required to be brought in to get into the crux of reasons for failure and then overpowering these reasons to convert failure into success. What Agile brought in was ‘harnessing over unpredictability’. Unpredictability was the most prominent reason that used to cause failures in traditional project management. This unpredictability used to happen in various shapes and forms; and during various project phases.
Agile is not a magic. It is merely as systematic and disciplined approach to focus on ‘micro’ parts of an elephant (project) rather than focusing on the wholesome and thereby losing control over it. Agile is a good learning for any project manager to get over the devils of a project.
A successful project closure brings in lot of happiness along with it. A series of successful closures bring it in a much wider and broader manner. Internal happiness reflects everywhere and starts sparkling outside also. That is the magic of success.
If we talk of 5 Ps that come along with Successful closure of projects, it could be:
Profit is always a key motive for any organization. Profits in turn lead to multi-directional benefits. It brings in business growth, team expansions, more customers, more business, employees growth and overall increase in satisfaction.
Power comes in shape of management’s confidence, empowerment, distributed and decentralized authorities and so on.
Pride is an automatic infiltrator that not only gets into management room but also on each and every employee’s desk.
Possibilities in terms of more business, customer sustenance, low employee turnover, higher satisfaction and growth, higher level of acceptance of challenges by team, trust and bonding.
Philanthropy becomes an integral part of management and project teams.
Project execution is the phase where all battle work is done based on inputs and raw material received from initiation phase and for the outcome that is required for project closure phase. Project execution hence needs to be well monitored, well planned and well executed phase. The engagement and discipline factor needs to be at its peak during project execution phase.
5 prominent Ps for a project execution phase can be listed as below:
Patience is the first key for a project manager that he needs to acquire. This is important for project manager to address to various issues arising from various fronts.
Persistence is the determination with which a project manager is supposed to move towards his milestones as per the plan.
Perseverance is important for a project manager in order to keep his teams motivated so that each key member of the teams are aware of the important tasks in hand and their timelines.
Pain is important as it is a very well known fact that without pain there is no gain. Pain here could come in shape of failure of teams in meeting their committed timelines, sudden contingencies, failures, major deviations etc.
Politics does not mean hardcore politics that a project manager should have that too its dirty side. Politics for a project manager means to be a strategist, diplomat and a true leader.
Recently encountered a project management model chart in a book where the author has presented three stages of a project – Project Initiation, Project Execution and Project Results. In project initiation there are certain factors that go along with certain ingredients to build some kind of raw material for the project execution stage. Mostly in the initiation phase you gather all first hand information that needs processing during execution stage; and build your teams, and infrastructure to handle this processing and initial data.
Customer requirement, business needs, business aspirations, anticipated business results are all inputs given by the customer basis which the project plans are made with end results in sight. 5 Ps that are essential to be part of project initiation stage and that too in their best form can be listed as below:
Purpose means customer and business requirements on the basis of which this project has come into existence. It is very important to understand customer requirements, aspirations and goals that are anticipated to be met with this application being built to cater to customer needs.
People include project manager, project teams, PMO, customer, management and other stakeholders. Very important to understand purpose of each and their expectations.
Passion is something without which nothing can be achieved.
Problem or the risks anticipated need to be taken care of in your risk management system so that project goes with least risk.
Plan is obviously going to be the vital organ of the whole game and ultimately a deciding factor.
If you feel, as a project manager, that the battle is won if you have identified and set your goals (your means yours and your teams) and you have formulated strategy to win over each goal, you are probably half right and half wrong. Half right if you have also a concrete plan for execution and half wrong if you thing that is the end of the road, and the beautiful work done so far is good enough to get the things executed on its own, and will draw out results, timely and in favor.
Logically, and in reality, once the goals are set and strategies are formed, there is lot more to do to get these dreams turned into reality. Right strategies formulated need to be executed in right conditions and environment so that the desired results in stipulated time are extracted. First and foremost important factor in execution of strategies is “Resources”. You need to be very clear on resource requirement to make your dreams come true. Right sizing of team, selection of right team members, and other resources is very important to arrive at.
Once the teams are in place and timelines are set for various milestones, nothing can be achieved if infrastructure is not in place. Hence it is important to identify right infrastructure requirement and put it in place before the teams are required to star working on a project. The role of a project manager for complete project is as important and critical as the role of individual team manager for their respective teams and roles.
A bird also has a capability, capacity and strategy to build a nest for its offspring. Well in advance it starts accumulating right stuff required to build its nest so that the delivery of eggs takes place in a right manner with least amount of risk to the life of newborns. A much earlier built nest has a higher amount of risk of getting damaged by the time the bird is ready to lay down its eggs. So is the case if the nest is half built and the time of delivery of eggs is reached. That is the difference between strategy and right strategy.
To build a right strategy in place a project manager needs to have a clear definition in front of him. What do we mean by definition? Definition is the definition of customer, customer requirements, business, business requirements and the resulting time agreed upon with the customer in terms of during and final deliveries. Once these definitions are clear to a project manager – it becomes easier to formulate a strategy for team size and composition, resources, logistics, individual team’s and for that sake each team member’s goals, deliverables and risk strategy.
A right strategy will be sustainable and capable to handle risks perceived. A regular review and control mechanism also needs to be in place and has to be considerable part of the strategy formulated. Adherence to strategy is important in terms of attaining goals set otherwise it will have no meaning. After all a kingdom is as good as its king!
There are numerous teams working on numerous projects all across the globe. Every project manager has its own way of handling a project. There are certain project management theories and practices that have been evolved during last two decades and few out of these claim to deliver hundred percent of success rate in project management, execution and closure. For any project there has to be a basis on which its foundation is laid. The basis for which a project team is formulated is customer and business requirements. Customer need not necessarily be an external agency and business requirements need not necessarily emerge out of an external business.
Well, when needs arise, a project also evolves leading a path for formation of project leader, project goals, project teams, project methodologies, project milestones, project stakeholders and their roles, project sign offs and closures. When a project manager becomes owner of a new project, his first role is to ensure that the goals for project are well defined with clear demarcation of roles and responsibilities along with timelines. When we talk of a well defined goals for a project, following things come into mind –
Business viz a viz Solution Sustenance
Risk Tolerance embedded in the business solution
Customer and business aspirations are nothing but the requirements which need to be clearly captured, approved and analyzed. Technical solution proposed must be rock solid in terms of sustenance and its capability of catering to changing business needs. And last but not the least, the solution built to cater to these customer and business needs must have been built taking care of all risks perceived.
The whole game of project lies into three keywords – Goals, Strategy and Execution. Once a project manager is clear about these three puzzles of a project, the whole scenario turns rosy provided he doesn’t lose his track till the end of the game. Goal setting is a good term but prior to coming to this stage it is important to understand the actual goals and its limitations. To understand it well a project manager needs to understand customer requirements as clearly as a crystal. If customer requirements are not clear, it will lead you to a wrong direction of goals setting and hence wrong strategy & execution.
That is why it is emphasized time and again to document customer requirements very clearly and in a structured manner but don’t hand it over to your development team before getting the complete document cleared, vetted and approved by a top level customer representative. Once the requirements are cleared from customer end, the internal project team needs to analyze it in terms of technical review which is based on these business requirements. A comprehensive technical document with clear cut specs is formulated which again is circulated and discussed among technical stakeholders of the project for finalizing the specs and move ahead for changes related to database, structured queries, coding etc. Obviously all this is not started, which is a part of execution, unless based on clear cut goals a concrete strategy is not formed and formalized.
The strategy would carry a number of milestones with projected dates and teams responsible whereas during the execution review meetings, team would be presenting the actual achievements against the projected ones.
Broadly speaking there are two categories of project managers based on their functioning style. Each style has its own way of functioning and that way of functioning has its own pros and cons. Both functionality are much evidently existing in the real world and both kind are having their success and failure ratio in their respective projects irrespective of various other factors and not majorly on the basis of their functionality.
Firs kind of project managers are quite attentive (rather quite aggressively attentive) in catching others attention and vice versa. They keep their senses intact while thinking rather than the mere facts and figures. They might seems to be carrying a good amount of their sixth sense functioning well. They do not give very high value to logic and intelligence and rather seek lot more beyond merely logic and intelligence. Such kind of project managers do not get on to the same subject more than once.
The other kind of project managers look more deeply into facts and figures (or rather see only into this area). For them logic and intelligence is on top of the list. They don’t get involved in stories so easily. For them reality of facts is more powerful rather than well cooked dreamy stories.
Recently am reading a book titled as The Devil’s Gate: An Impossible Journey by Deepak Kripal. In this book there is a very interesting story about a dog who fell in love with a demon who was not as bad looking as other female demons. The demon also reciprocated and both decided to spend their life with each other. Meanwhile the father of demon decided to call all male demons to select the best among them to get his daughter married to him. Dog comes to know about it. He also decided to join the contest. the contest was to sing the best song and whosoever makes others dance to his tunes while singing a song of his choice would be eligible to marry demon girl in question.
The demon girl requests dog to not to join the party as she knew that dog is not at all a good singer and if he would sing there in the party, he might sing so bad that her father might get him killed there and then only. Dog agrees to it and promises that he will not come there – bade her goodbye – and both promise to remember each other forever, wherever they live and with whomsoever.
while the party is on and each demon is waiting for his turn to get the hand of girl demon by singing at his best, some got quite enthusiastic for the performance given by them and were quite hopeful. Suddenly the dog joins in and tells demon father that he wants to marry his daughter. Demon father gets very annoyed and warns dog that if he fails to sing best of all, he will be killed by his soldiers. Dog agrees, closes his eyes, and starts singing a love song keeping demon girl in his mind, but while singing keeping his eyes closed, he was almost sure that he will be dead by the end of his song.
Surprisingly when he opens his eyes, everyone is so mesmerized and dancing that he gets amazed. Demon father calls his daughter and marry her with the dog.
Just a signal to a Project Manager – if he has the same art of making all stakeholders of his project dance, on his mute tunes by singing at his best!
Our friends and enemies are not aClways where we expect to meet them
An excellent line that fits well when we talk about software coding and testing. A coder build the code based on the requirement. Definitely it depends a lot on how well a coder has understood the requirement before he jumps into the ocean called coding. A wrong direction in the ocean will of course lead to a different direction than the one that is targeted for. The same is correct for coding. If the customer requirement and ultimate goal is well understood, the coder will be able to swim in the right direction and produce desired results.
Same goes well for testing also. Once coding is done and unit/smoke testing is done by coder, it is handed over to the testing team. The matter regarding leading wrong direction and undesired destination as mentioned above, is true for tester also, as it is for coder. A tester has to be careful enough not only to seek holes in where he perceives them to be available most, but also at other hidden and unanticipated places where a tester perceives them to be least.
I have become a big fan of Saga of Wealth by Cassia Cassitas and there is already a post on my blog about Two Excellent Project Management Learning from the Book Saga Of Wealth
Lesson 1: History is made with numbers. If you pay attention to them, you will find the answer to everything you wish. They will teach you the secrets about things and people
For a project manager both numbers and people are crucial and important. Numbers means deliverables, milestones, timelines, deviations, timely closures; and people means teams, customer, management, other stakeholders. So if a project manager has to have a successful career, he needs to have successful projects and a successful project not only means timely closure and sign off but beyond that. A project where customer becomes so delighted that he openly becomes a brand ambassador of your commitments, deliverables and right attitude; in such a way that it start getting you more and more business; there is nothing like it.
Lesson 2: In the business world, an investment is considered “covered” if the borrower’s cash flow is sufficient to return as much capital as the capital loaned. On the other hand, if income is sufficient to pay only the interest on the loan and if new loans are needed to pay off the principal, the investment is considered speculative.
So what is means is that in the world of project management a project is considered as successful if the customer’s business requirements automation in the product are met so significantly that the business either starts getting higher business equivalent to the amount invested in the product development or the people become so efficient and productive equivalent to that amount. Definitely one thing is sure that the return of investment is never overnight but over a period that is well thought of by the investor.
Ghana, with a target of transforming the country to a completely middle income nation has initiated a project titled as e-Ghana Project that comprises of a number of intensive Information Communication and Technology (ICT) related sub projects with a total estimated investment of around USD 100m. This e-Ghana Project actually is in fact a component of World Bank’s e-Transform Project. e-Ghana Project’s main sub-projects are e-Education Project, e-Health Project and e-Justice Project. The initiative speaks a lot about the substantial motive behind this project. A country that takes an onus to optimize and enhance pace of health, education and justice for its people; leads to a remarkable future.
The e-Education project basically is to provide high quality of education to the most neglected and ignored youth of the society. The focus is to create a database of all youth of Ghana with the level and quality of education status of each. The target is to bring all to a dignified, widely recognized and high quality level of education.
Similarly e-Health Project is to make all the medical facilities of the nation highly technology, information and communication equipped. For this three medical institutions have been identified for pilot run, which are – Zebilla District Hosital, Wa Government Hospital and Korle-Bu Teaching Hospital. A huge transformation is being anticipated once these three locations after deployment of intensive and highly effective ICT facilities.
Similarly for e-Justice Project the main focus is on making justice system of the country highly effective and efficient.
Ultimate goal was not to save $5 million when City of Tyler decided to start this six sigma project but to run it successfully and close it in time. As we all know a six sigma project is always time bound and has to bring results in financial terms. Lean Six Sigma is a one step ahead version of Six Sigma that is a combination of Lean and Six Sigma. Basically Lean Six Sigma focuses on elimination of Mudas (or wastes) in a process thereby improvising to a level of enhanced performance. Mudas or wastes can be in terms of defects, money, time, resources, inventory or non-optimized steps in a process. So here, in the city of Tyler, a city in Texas, the United States; Lean Six Sigma was deployed to manage multiple volume of projects running for various purposes and various lengths.
The complete effort returned a saving of an amount of USD 5 million by focusing on identification of Mudas and their elimination from the process. The senior public relations expert of Tyler, Serena Butcher declared complete satisfaction for the results achieved from this Lean Six Sigma Project. The overall target of identification of wastes in all aspects of Mudas and thus achieve their target of saving time and money, ultimately gaining in efficiency and deliveries.
Whenever a project gets initiated there are certain teams that come into place, there are certain guidelines that are chartered out and there are some milestones that are identified as major benchmarks to demonstrate the appropriate speed and progress of the project. But prior to that first few things that come to the mind of a project manager can be listed down as below:
- Final Goals: It is important to understand what is the ultimate goal that customer wants to achieve.
- Value Addition: What is the value preposition you are adding to the customer beyond his expectations. There must be some value addition to bring in the customer delight.
- Audience: Who are your audience who would need a constant broadcast of project updates from you in appropriate intervals. Understand very clearly the amount and frequency of information required by them rather than deciding on your own.
- Top Management: Definitely you are not required to engage top management for day to day activities of your project but a top level bird view is important for the top management to updated regularly. Also a timely raised alarm in case of any irregularity is also important in that aspect.
- Risk Management: Identification of anticipated risks, review and mitigation plan.
- Team Empowerment: How do you plan to empower your teams so as to keep project going in a desired pace rather than getting hiccups for the sake of requirement of approvals for small entities.
- Resource and Finances Management: A proper charter is very important.
Recently finished reading this 380 odd pages fantasy, young adult, paranormal fiction novel Secret of Omordion by Nande Orcel released by Abbott Press in October 2013 and the book has been doing well. Though the book is not technical, nor is it written about project management and quality assurance; but there are certain golden lessons hidden in the story of Secret of Omordion.
The story is about 5 teenagers who belong to Dokami clan supposed to hail from various planets and settled on Earth, though the count is not very limited. These five teenagers – Atakos, Cristaden, Fajha, Zimi and Zadeia put on different locations in the country but are gathered at one place – a boarding school – for 10 years – away from their parents – so as to get trained to groom as great warriors and fight against the enemy powers continuously fighting against their country to defeat them and overpower the country.
These five teenagers though initially are not aware about their powers inherited being belonging to Dokami clan, start believing in themselves, once they are chosen for this special mission and gradually start discovering their special powers hidden within them. So is the case with project managers. One has to believe in himself once has has been chosen for a special mission of handling, managing and succeeding in a project. Once selected, tighten your belt and start the journey of your special mission with full blow.
No project will be away from ups and downs in its journey through various phases. Only way to handle the tough situations is by discovering the special powers within you to handle these situations and emerge as a clear cut winner.
In my previous post – NFC Project At City Stars Mall Cairo: A Step by Step Walk Through – I gave an oversight of this pilot project that had to be deployed on 2 floors of City Stars Mall in Cairo, Egypt for 400+ security guards attendance, shift management, real time control room management, prompt action for shortfall, supervisor patrolling, incident recording and reporting to control room with video/photos streaming.
The software and hardware requirement is mentioned in the previous post. Deployment was as below:
RFID wall mount tags had to be fixed on inside and outside the building. RFID enabled ID cards were issued to all guards and supervisors. Each tag while fixing on individual location was configured for the first time with location id, tag id with the help of app residing in Nokia 6210 Classic NFC phone. Similarly one card was issued to each guard with appropriate configuration of information of guard id, tag id. The desktop app had all the information of guard shift schedule for the month, guard details etc. similarly the location id had further derails in the master regarding floor, patrolling sequence etc.
Each guard had a duty position for static guards. First tagging was done on NFC phone lying with the supervisor at the time of entry from any of the entrances of the mall and then once posted, the supervisor used to take a round to tag the location tag and guard tag once again to ensure that the guard is posted at right location.
Similarly process of patrolling plan, actual patrolling, incident recording etc. was deployed successfully.
I was in Cairo for a period of 15-20 days to deploy and sign off this NFC based pilot project in one of the most renowned malls in the heart of Cairo City – known as City Stars Mall. City Stars is a two blocks 8 story huge building.
Project Requirement: Around 400+ guards coming in various shifts were having manual attendance, patrolling and monitoring system which was wasting a lot of time and confusion. Another reason for this pilot was that one of the guard’s body was found in one of the emergency exit area after 4 days of his death during which he was being assumed as an absconder. This attendance, patrolling, incident recording/reporting and monitoring was required to be automated in a way that a real time dashboard would be available with the centralized control room so as to manage the whole show optimally.
Software and hardware requirements:
Nokia 6210 Classic – NFC enabled, data enabled
RFID Tags – wall mount
RFID Cards – ID cards for guards and supervisors
Control Room – Desktop application with internet to get real time data.
What is a NFC phone – NFC is near field communication. An NFC phone is basically an RFID reader that can read RFID tags/ cards and with its data enabled, it can transmit information in real time to back end team.
With the help of above, the pilot was done successfully on two floors of the malls in flat 15 days.
I will explain the execution and deployment process in next post.
In my previous post we talked about three basic elements of large sized software projects and how to manage & control the first two elements.
Correct understanding of Project Scope
Optimized coordination among various teams working on the project
The first two elements being correct understanding of Project Scope and Accurate Project Costing & Scheduling. We also learnt how these two elements discussed in the previous post are tightly inter-correlated overlapping each other to some extent but success of one does not ensure the overall success of both. An equal amount of attention and focus is required on both the components in an independent manner. Similarly even if you, as a project manager, are able to control well over the first two elements, the third – Optimized coordination among various teams working on the project – is usually a cumbersome task bundled with a large volume of hurdles which are mostly invisible and hidden in nature, emerging all of a sudden from nowhere.
Most of the delays happening in a project’s timelines come out with this root cause that either one of the team did not complete their tasks in time, thereby creating recursive impact on the delays; or the coordination among teams who had to work on the project in a sequential manner did not plan in such a manner so as not to lose time during the handover-takeover phase.
Such hiccups are usually overcome if there is a regular review of tasks planned and tasks completed on a daily basis. Probably Agile is the answer to overcome this bundle of hurdles in an effective manner.
Three main challenges that usually go unnoticed in larger software projects could be listed as below:
Correct understanding of Project Scope
Optimized coordination among various teams working on the project
Everyone who has worked on a software project would agree that once you get more into day to day firefighting in managing a derailed project, the overall broader and wider view of project gets blurred and hence goes of out of focus. Though you feel that the efforts being put in the project will get it back on track but in reality it gets farther away from the tracks and hence increases gap exponentially rather than bringing it back on track. Team sizing and project scheduling depends on accurate project costing. Oversized team does not ensure accurate adherence of project timelines. Rather if by mistake you have taken more than required number of members in teams, logically it should result into earlier closures of project milestones. It does not.
Project costing also depends on correct understanding of project scope. If scope is not understood well, it might result into a weird project scope that further results into wrongly sized teams and project timelines. Even if you have bene able to understand project scope well and get it documented & vetted by relevant stakeholders, it does not guarantee still that you will be able to form right sized teams and build your project schedules with equal correctness right from the beginning. Usually the learning comes along with the project progress.
I will talk about Optimization in team coordination in our next post…
Logically roles of the three teams – Project Monitoring, Project Evaluation and Project Audit are sequential and slightly overlapping in nature but there are differentiating factors ensuring a need of separate teams to conduct these separate activities. Project Monitoring is the process to analyze the project growth and find out any gaps so as to bring the derailed project back on track by taking proper measures to mitigate the risks encountered. Project evaluation on the other hand is the assessment and evaluation process with a purpose of finding out major learning points so as to ensure proper sustenance to upcoming projects and ensuring that risks encountered during the current project do not recur.
Project Audit is the process of assessing the completed project in terms of legal and regulatory compliance in terms of financial transactions – mainly expenses and income entered in the books of accounts. It necessarily happens once the project has completed and signed off. The main purpose of project audit is to ensure management and other stakeholders about no irregularities taken place during the project and if there are any, that come to notice of the team, then a proper analysis and mitigation is ensured.
Basic purpose of Project Audit is to focus on the long term goals of ensuring acquiring a learning from each project and ensuring no repeat of same kind of mistakes.
Unlike constituents of Project Monitoring Team, where the members of the team are from internal management, the members of Project Evaluation Team comprise of members from external stakeholders also. The main reason for this difference is that whereas monitoring is the sole responsibility of internal management, and hence respective key members have to ensure its consistent progress; in case of project evaluation there is a process of assessment of shortfalls and the remedial actions taken in case of shortfalls.
Project Evaluation is the process of assessment of achievement of project goals, team efficiency, factors that impacted on project adversely, relevant other factors responsible for non-achievement of project goals and also the assessment of mitigation plans. Overall purpose of Project Evaluation is to ensure that monitoring process is foolproof and in case of any gaps found in the monitoring process, how to ensure that there is no gap left.
Whereas Project Monitoring periodicity is more frequent depending on the project methodology adopted, project evaluation is usually planned with longer periodicities. For most of the projects it happens at the end of the project. In some cases, there is a mid-term evaluation and then the final evaluation. In project monitoring, the emphasis is more on finding stopgaps and their remedies. In Project Evaluation it is more of accountability, Impact analysis and financial gain/loss.
Project Monitoring talks about a continuous and periodic analysis of a project plan to understand the timelines and milestones as per initial plan and find out the gaps, if any. Basically its main purpose is to analyze the progress of project to see if the desired goals as per plan have been achieved or not. A gap in achievement of stipulated goals might call in for a rapid action, management’s intervention to take some urgent decision or an emergency meeting with all stakeholders. Monitoring process is usually managed by an internal project team comprising of members fr
Project Monitoring team’s main role is to keep an eye the ongoing project to monitor its progress, and take immediate mitigation action in case of a gap is found out in planned goal due to any risk. The mitigation plan that is now a new component of the project plan is updated to all stakeholders respectively with the newly defined timelines for achieving project goals.
What PRINCE2 ensures is that it enables you to drive your PRojects IN Controlled Environments and thus the name PRINCE2. Now what does it mean. It means that firstly the methodology enables you to understand all the controlling agents of a project that can be held responsible for its success of failure. Without this understanding you will never be able to make your projects run in a controlled environment.
There are 3 major components in PRINCE2 that are very important to define and measure. These are – Output, Outcome and Benefit. Let us understand what each of the term means. Project Output is overall product that results into during the project and is deployed at customer location to help him get the business results as per the expectations. The product built is the business requirements of customer that have been translated into an application. These products could be direct or indirect, objective or subjective, tangible or intangible; but definitely are clearly visible and desired.
Project Outcome in PRINCE2 is the measurable changes that take place in an organization while using project outputs. Definitely any product has to have a usage strategy and results expectations.
Project Benefit is the improvement that is resultant of project outcome. Definitely this improvement has to be clearly measurable and has to be resulted to be an advantage to the customer. Project benefit is always tangible and measurable; and can be worked out in financial terms.
If you are able to tie a successful marriage knot between the people (various teams working on a project) and the business requirements, in any project, during its project initiation phase, you have ensured an achievement of a very high rate of success for your project goals. That is what Agile development methodology does if you understand it well, adopt it by heart and put it in the blood of your project. You can very well find out the difference in the way you have been driving your projects towards success versus the actual success rate, once you adopt Agile strategy and make it an integral part of your project.
Agile talks about innovative approaches to be adopted in collaborating your various teams working on a project in such a way that everyone becomes equally engaged in a project and hence effectively a substantial partner in the success of a project. The whole team becomes a well synchronized unit that works in a perfect rhythm to move towards the project goals and achieving those goals. Ultimately it is the business requirement that leads in formation of business application development strategy and other strategies around the main strategy keeping complete attention intact on the nucleus of the requirements.
The strategies formed are so strongly built to optimally sync each individual’s vision with the business needs so as to bring in a total transformed culture across various teams working on the same project. Once this culture reaches to its maturity level, there are various things that start happening within and outside the organization. Teams feel more satisfied, customer pumps in more business, overall commitment and delivery mechanism improves, quality enhances, and a consistently optimizing environment builds in.
PRINCE2 is other words is PRojects IN Controlled Environment. The main goal of PRINCE2 methodology is to form an effective project management mechanism. As we are all aware that any project start with Project Initiation Phase and the first thing that is substantial in that phase is the project description. PRINCE2 has evolved with tremendously effective and result oriented templates to have a near to perfection mapping of business case with the project description so as to have a direct relationship between business requirements with the product development plan. PRINCE2 also helps in following, managing and controlling the plans with the help of its powerful project templates.
An important point to note here is that business case is one of the core component of Project Initiation Document in PRINCE2 and remains a prominent point of reference throughout the project lifecycle. Logically any system you adopt or follow, the main reason behind it remains to be a good performer and effective during the project management’s various phases. The system adopted must be able to make you more comfortable, effective controller, perfect driver and proactive risk mitigating agency.
Ultimately it is people on top of any system who drive a project or it is the system that drives people towards success during a project – choice is yours. Even with the best of systems deployed in your organization, if you are not able to drive your projects towards success, there is some wolf among the sheep in your core management team who is strong enough to impact your driving force to wrong direction.
A set of software development process, procedures and methodologies, know as Agile Software Development works entirely on a different kind of strategy as compared to our legacy software development processes. In agile software development we talk about Iterations and incremental development. The focus here lies more on building of self driven & self organized cross-functional teams that are responsible for concrete evolution of requirements and solutions.
In agile software development you talk of quick outbursts of results rather than a goal set for software development team to travel on a long road to reach to their destination. Here emphasis is more on milestones that are small pieces of ultimate goal that is required to be achieved. And these small pieces are like building blocks that enable you to reduce your distance from your final destination by achieving each milestone and reducing distance to your goal block by block.
For further insight you can refer to this fantastic article.
Whenever you talk of a set of activities involving a number of teams in managing a project, it is termed as project management. The set of activities that need to be catered to in project management are project planning, project organization, project team, project control mechanism, project management procedures, methodologies and processes. Why these set of activities are important in project management – to reach to a successful project closure, to achieve your project goals and to get financial and new business results in a favorable manner. Definitely in order to achieve these goals, you require a number of teams to perform the necessary tasks or activities. That is the whole ecosystem of Project Management.
Now, in this ecosystem there are some adverse forces that keep active to generate some negative impact, to drift teams away from performing desired tasks, and in slowing down the whole mechanism in reaching to its desired goals in desired timelines. These negative forces appear in different forms and shapes – sometimes in an anticipated way and sometimes totally like a ghost appearing all of a sudden – unannounced and unnoticed.
A smart project manager would always keep cool when the tides are in favor and keep thinking on the ways to tackling the situation in case of adverse situations. The ultimate goal of understanding the whole gamut of project management ecosystem is to learn the art of sailing smoothly during adverse situations.
Recently I interacted with a professional photographer from Mexico City and while learning about his work I could sense that they have a similar (if not same!) kind of Project Management activities to manage their project assignments. Their projects also vary in size thereby earmarking the duration of a project. These assignments are also of similar kind of nature as software projects – overseas, offshore, domestic, international and so on…
And so I decided to talk to Rodrigo to understand how does he manage his projects and other aspects related to his projects’ management.
Rodrigo Jardón, September 20th, 1987
Mexico City based photographer. Rodrigo works to cover social issues ranging from demonstrations in Cuba to refugee camps in the Western Sahara and Palestine, and from sporting events in South Korea to rock concerts in Fargo, North Dakota.
He is usually a concert photographer but since March 2012 he has a personal project of photo essays called “Tourism in the lives of others” on his webpage. It contains sequences of images ordered in a narrative to transmit a feeling more than information, closer to poetry than documentary, as he sees it.
How challenging is your work?
I have basically two works: Concert photography, where I make money from, and Documentary photography, where I cover social issues and even violent demonstrations. That is the challenge: to combine those two lives at the same time, but it is also the best part as it helps me to keep balance of myself.
What basic skills are required to become a good photographer?
Devotion for your work.
When did you realize to take photography as a career?
When I realized I that if I worked hard enough I could use photography as an excuse to travel, free concerts, and even make some money!
What are the main challenges in this career?
As a freelance photographer I think the hardest part is to administrate your time and money, as you are your own company.
How many projects do you do in a year?
Around 2 or 3 big documentary projects, the rest of the year I do concert photos.
How the sizing of photography project is done?
I usually save money and go to places to get exposed to situations, as Susan Sontag says: “The camera makes everyone a tourist in other people’s reality, and eventually in one’s own.” (Melancholy Objects, p. 57).
Does it require a team to perform these projects?
I usually work alone taking the photos, but I like people writing about them in order to know their perception, the last collaborative project I did was in the Ozark Mountains in Arkansas with writer Alice Driver entitled “My homeland”.
What various roles are you required to perform in a photography project?
In my photo-essays I am the producer of the content, but I think that the most important role is as an editor, when I select and arrange the images previously taken in order to evoke emotions in the viewer, this can take days or even weeks.
What career did you plan during your education days?
I wanted to be a book illustrator.
What languages you can speak and write?
Spanish and English.
What are various styles or genres of photography?
It is often divided based on the use of the image between art and documentary photography or candid and posed depending on the technique, but nowadays everything is mixed. My favorite genre is the photo essay: a set of photographs that are intended to tell a story or evoke a series of emotions in the viewer.
When did you start photography?
My brother got cancer about 13 years ago, and my mom bought me a basic digital camera to take photos and videos of him. When he died there were only those images, and this is how photography became important in my life.
When my family was recovered, I traveled with my mother in her fieldwork. She is an educational researcher, and I accompanied her to take photos to illustrate their research, especially in the Mexican borders.
Would you like to share some of your major projects?
What are your forthcoming projects?
I`m looking forward to finish a series of photo essays on in the different countries of the divided Kurdistan, in order to reflect the subtle violence against the Kurdish people, and looking for writers to add texts to my previous photo essays in order to make them more collaborative.
Driving a project to a road that ensures smoothly progressive flow with least number of speed breakers has always been a prime requirement in project management and that is where the role of a project manager comes into picture. A project manager need to have more of leadership qualities to attain higher amount of success in his project ventures. That is what the new book The Power of Project Management Leadership: Your Guide on How to Achieve Outstanding Results by Laszlo A. Retfalvi emphasizes on.
The book talks about crucial requirements for the leadership that holds and controls project management, to run a project successfully in today’s scenario of higher complexities, greater demands of zero defect, stricter following of timelines, tough roads and highly aggressive/volatile customers. There have been many books earlier on guiding how to run a project successfully or how to handle project manager in a more effective manner. The power of Project Management Leadership by Laszlo A Retfalvi focuses more on a project manager as an individual to empower him for managing a project by means of inculcating certain leadership qualities that can help him managing his projects in a more effective manner and having effective and timely closures in a successful manner. The book talks about marrying management and leadership in such a powerful manner but with a concrete balance. If understood and followed well, the book can act as a superb guide to a project manager to acquire higher levels of excellence.
Overall The Power of Project Management Leadership: Your Guide on How to Achieve Outstanding Results by Laszlo A. Retfalvi is an excellent book and a must read for all project managers to find out the hidden treasure of leadership skills within, polish them and use them effectively to acquire excellent results in their projects.
Let us consider we have reached to the final lap of project management. Business requirements were captured well. Current business scenario was captured well. Gap analysis was done successfully and signed off. Development took off well and landed well in between covering different QC destinations where various passengers ported and deported. And finally it has reached to a stage of deployment after exhaustive testing is completed. The team has landed at customer site to sit along with key process owners and key process users (mind it that process owners and process users are different usually depending on the size of organization, but both are key drivers of the business process of their respective field/area as both have important and critical credentials in running the show).
The broad level run of software developed might cross key process owners’ den successfully but might land into a large list of queries when it lands into the lap of key business users for their respective modules. The micro level in-depth requirements that arise at this stage are inevitable and need a firm addressable confirmation from the deployment team (who in turn will have to go back to development and testing team for incorporation of these changes) unless the changes required are too weird and out of scope.
For instance – initially – while capturing the business process – for a cash voucher flow – current scenario would be a paper voucher created in business that goes to various stages of approvals before final payout. The clear cut requirement would be for automation of this complete process along with the workflow. A last minute call at the time of deployment could be logistics of workflow, mobility, rejections logic that could seek changes.
Project management, project needs, software development, software development technology – methodologies, policies and processes have undergone a major transformation during last 20 years. There have been many drivers and derivatives that emerged out of one big revolution that can be held responsible for this and that is Internet.
Internet has brought out a tremendous revolution all across the globe. It has in fact brought globalization to every corner of the world and probably has played a unique role in marrying globalization with localization. What it means is that awareness about what is happening across the globe was very much limited to printed world with very low audience. Internet has been able to bring all on a common platform with awareness about best of everything happening at some corner of the world or other. All good and bad got published over the internet almost in real time and near to real time environment thereby bringing awareness about latest technologies, success stories, good organizations, failure factors and universal learning.
Connectivity has become easier, faster and reliable. A project team sitting in one corner of the world, easily manages to connect with the customer in other corner of the world over a virtual platform for communication, video conferencing, document sharing and meeting reviews. Even deployments, training and handovers are taking place now over a virtual environment and shall be a big reality sooner when no physical movement of a project team would be required at customer location – be it for the purpose of understanding of current business scenario, business requirements or for product development, deployment, training etc.
When there is a gap between project management, project processes and performance management; it becomes a bottleneck for project manager to move out of a tunnel with no visibility of light. The main reason lies behind this is that all energy flowing in the project starts flowing in a conflicting manner thereby nullifying the positive impact and gradually generating negative impact on the progress of project. Project manager has to be quite tactic in this aspect so as to handle such conflicts strategically in order to avoid any packet of energy going waste.
There are certain business needs specified by the customer that are required to be built in an application to handle the business flow of the customer. To achieve this, the teams engaged for this project need to follow certain project methodology that is most suitable for this kind of project and then in order to achieve success there is a need of following certain processes defined & documented in that particular project methodology. There would be certain documents, certain formats, certain procedures to follow to keep project moving in right direction and also to make all stakeholders stay on same page.
The important factor here is to put back the rail on track that has got derailed due to certain non-adherence or certain misalignment. So the big question comes here is that there has to be a mainstream person, mostly project manager, who should take charge of alignment between the teams, processes and various stakeholders requirements.
Project Management landscape has changed over a period of last decade. The change has been tremendous, consistent, and substantially visible. Changes have happened in terms of achieving success, clarity of matter, project methodologies, value of timelines & adherence, PMO, and finally the role of project manager itself.
In earlier project management scenario, a project manager was more of a symbolic entity which in last few years has emerged as a powerful driving and deciding force within the sphere. In earlier days project manager was more towards signing off docs and sign offs. There used to be ample reasons for project delays and failures that were thought to be beyond control of a project manager and hence in most of the projects where there were substantial delays or failures, the project manager used to use this armory of ‘genuine excuses’ and hence saving his neck.
Time has changed and now a project manager is supposed to be responsible for any kind of preempted risks or the unanticipated ones, howsoever severe or drastic they are in nature. The project manager is responsible for mitigating all such kind of risks and drives his project towards success or out of risk zone so as to take the whole team towards comfort zone.
That is why today’s project manager has to be more proactive, communicative, collaborative, innovative and alert.
When the product is ready to be handed over to testing team, the testing team needs to ensure completion of certain tasks before it actually starts the testing of code handed over to them by the development team. These important tasks ensure proper understanding of scope of testing, and help in preparing complete coverage of testing by building exhaustive (and relevant) test cases by the testing team. In any case these activities would be happening in all the cases but only need to be crosschecked to make it happen in a formal and structured manner.
These activities are:
Business Flow: Along with customer requirements, testing team needs to understand the real life business flow at customer end so as to align it well with its testing strategy, coverage and completeness.
Business Cases: Real life business cases need to be studied by the testing team for both the scenarios – one, for the current condition where the business might be handling the situation on a legacy system or manually; and secondly, how they would like to see it happening in the newly built application and environment. The simulation of both scenarios is quite important to understand what-is and what-needs-to-be situations.
Taking further on from few of my earlier posts on Project Plan and Project Management –
Here is some more insight on Project Planning:
Any project when goes in its execution phase, gets bundled with a set of assumptions, is a well-known fact. These assumptions vary on the basis of different factors that control a project. So we need to understand how do we tackle a situation where a live situation to go active in a few days/ weeks/ months from now is dependent on certain factors which are hypothetical in nature. There is a conflict already built, if you really notice, between a real and a hypothetical environment where both are banking on each other for making it a success.
It becomes quite important to understand what those hypothetical situations are known as assumptions, and what the basis on which it is being built. A classic example is team sizing which is decided on the basis of scope of work and past experience in handling similar kind of situation. For example it is worked out that the total effort for a particular task of development is say 20 man days and this development work is to finish in 5 days thereby deriving a requirement of 4 persons to be deputed for this particular task. Now important to know is the task itself – whether it is possible to split in 4 equal portions and handover each portion to each of the developer to finish in 4 days each so that one day is kept as a buffer, or the job is sequential where the second person can work only if first has completed the first portion.
How often do you wonder as a non testing member of a project team regarding the basis of categorizing bugs, setting their priority of fixing and their allocation to respective development guys? Logically there has to be a science behind it otherwise the exercise doesn’t make any sense. But above all whosoever takes the onus of prioritization of bugs needs to have some fundamental things in place.
First of all the test lead must have a concrete and complete knowledge of business and the business requirements – on the basis of which the project has been initiated and the product is being built. Based on the business requirements and priorities; and the kind of bugs that have been detected by the testing team; an alignment can be formed on the basis of which these bugs can be sorted out for their severity and priority. There has to be, definitely, a relationship between the severity of bug, and the priority being set for it to get fixed.
Ultimately all bugs have to be fixed by the development team. Then have you had another thought in mind, ever – why severity and priority is set for a bug, if all have to be fixed at the end of the day? Answer is simple – bugs with higher severity and priority shall go to highly expert members of the development team. And also when come back for validation – the same concept is to be applied among testing team members too.
Bug management complies of many of the activities related to bugs. It comprises of bug identification, documentation, reporting, action and closures. Once an initial set of bugs are reported to development team and they report back to testing team as fixed, the testing team needs to revalidate about the proper closure of these bugs. Validation of closure not only should be about the closure of reported bugs but also to ensure that there is no adverse impact on the application functionality and flow due to the fixing of these bugs.
So logically while validating each bug as fixed, there is a need of exhaustive amount of test cases that ensure testing as stated above. There could be cases where the bug identified and reported has been fixed and this fixing in code has put no adverse impact elsewhere. But it may happen otherwise also that the bug has been fixed and it has left an unwanted impact somewhere else in the code that now needs to be identified and fixed. There could be a third scenario where not only the reported bug has been left fixed to its fullest extent but while fixing it a new set of bugs have arisen.
Now, the most important thing: who among the team is focusing on improvising level of coding where the numbers of bugs reduce in every iteration? A special attention on taking a note on every code release is also important – if the severe bugs are getting reduced or not?
Business knowledge is equally important for two major teams working on a product – one, the development team, who has taken the burden of converting some key business processes into automation; and another, the testing team, who takes the onus of making the developed product – bug free – before it is decided to launch for production environment. A tester has in fact multiple roles while testing a product. While the development team has a big document – titled as “Business Requirements” to bank upon while development of the product; the testing team has to be more practical in terms of getting into the shoe of customer – when it comes to testing of product.
An effective testing has to look at product that has come for testing with multiple lenses. It has to ensure complete catering of business and customer needs, it has to ensure excellent usability and reaching at par with the expectations of the end users who are going to run business with the help of this newly developed product. Functionality of a product asks for a big amount of alignment with the real business environment.
An improperly or incompletely understood business requirement would lead to its equivalent development that would lead to wrong business results. Now the onus lies on testing team to find out the gap in developed product and the original business requirements. It might call for a fresh round of repetitive efforts by development team, but it is worth doing it rather than releasing an immature product in production environment.
Most of the time whenever a product has to go to testing team, the whole attention starts going into ensuring complete coverage of product, exhaustive testing, test results, test cases, test strategy, test plan and so on thereby thinking that the whole success of testing lies in adhering to all these factors and their compliance. If for once the focus is diverted to paying more attention to what enhancements need to be done while coding so that the bugs are minimized, probably it will make everybody’s life happier.
The focus on enhancement of coding process, procedures and methodology with only one thing in mind – minimal bugs – could make a big difference – in a permanent manner. Imagine that if the efforts and time in coding remains same but it is done in such a manner that there are minimal bugs in it, it saves a lot for later stages. First of all it starts building an extra level of confidence in all stakeholders the moment they realize that the same time that goes into coding, now saves a higher amount of time of the testing team as the coding has got enhancement and is now near to a bug free mode.
Another important factor is that the efforts required post coding, by testing team in finding bugs, reporting it back to the development team, and then bug fixing by development team; if now starts taking lesser time; it saves a lot of recurring efforts.
Bug Management is something that has not been standardized in a universal manner. Usually its management, reporting pattern, closure and confirmation process varies from organization to organization and there too the complete adherence to the process varies. At places you will find a very structured and elaborated bugs management system with each and every step being followed and managed aesthetically while at other places the bugs reporting itself might not be too structured.
The variance in adherence depends on many factors and culture being followed within an organization. It also depends on efforts being put for enhancement of processes, benchmark and stakeholders’ engagement. It has been found that if a same piece of code is handed over to 5 different testers for an independent testing by each, the reporting mechanism, level of testing, number of bugs etc. would vary in a very random manner. This inconsistency gives rise to a number of flaws and gaps in the process and mechanism.
The same variance would happen in case of the same team of testers is given a different set of products for the purpose of testing. The test coverage and test results would not be consistent unless and until the testing team follows a well-established process of testing that caters to some properly defined processes and procedures in order to maintain a universally acceptable testing mechanism.
It has become as well proven fact that a tester cannot become a good programmer and a programmer cannot be a good tester. It does not mean that a programmer doesn’t know how to test or he doesn’t have the capability to test the code he has written but testing his code as a tester is not possible for a programmer. There are various reasons given on the reason that why a good programmer is not a good tester in one of the earlier posts. One of the main reason is that a writer cannot be a critic of his own writing. Same goes true for a programmer. Programmer loves what he writes and himself would not love to find out fault in what he has created.
Even when there is a testing done by a programmer/ developer after writing his code, the prime thing in his mind remains that the code has been created by him and that is what holds him going into customer’s shoe and looking at the code from customer’s perspective. Whatever a programmer tests in his code is the technicality of the code. Two important things that he misses to map with his code are – one, the business flow; and two, the usability. At many instances I have discussion with developers on what they have written and what business requirement had been. And on such instances most of them argue to accept it as per the code written and express reservations in changing the code as per business requirement, by giving different reasons.
Role of testing team is to look into enhancement of the application built for a customer and making it as near to the scope and reality of business as per the expectations of the customer. If development had been free of errors or bugs, there would never have been a need for a separate dedicated testing team. Testing done by development team would have been sufficiently enough to launch the product, but it never happened. Why it does not happen is a separate story.
As already suggested in one of my previous post here, it is important for testers to follow certain set of guidelines to perform their task of testing as per the expectation of customer and other stakeholders as ultimately it is the product under scrutiny that is going to speak louder than the commitments and promises made to the customer. Because if it is not the testing team that catches the bug in the product then probably no one else before the launch of the product. And a bug encountered at a later stage when the product is launched and is catering to the business needs on a live environment, it would be too late for so many things.
A bug encountered at a later stage once the product is live, it not only hampers the reputation of product and the organization behind it, but also the future prospects of the organization. Documentation, well written processes and adherence to them, regular reviews and finally a sincere feedback plays a major role in keep moving in the right direction during a project.
Bug fixing for development team is as serious affair as a new built, or rather it must be a more serious affair. It is quite phenomenal that no product development has ever been 100% bug free. In fact importance and necessity of testing phase and testers is increasing exponentially. Again a general mistake that is done is that testing team takes it lightly after it has done first time exhaustive testing of the product once it come to them for testing after completion of development. An equal plan, set of test cases and same amount of seriousness is required to testing after bugs have been reported fixed by the development team and the product comes to them for testing of bugs.
It is good to do some iterative development- testing – bug fixing – testing here in order to perform it in a collaborative manner so as to save time and release in time. After a cycle of bug fixing has been done by the development team, the task for testing team become double fold. One – to ensure that the bugs reported have been fixed and two – there has not been a birth of new set of bugs while fixing the first set of bugs.
Reporting, documenting and reviewing is a good mechanism to manage the show during this cycle.
Test strategy, test plan, test schedule, test cases and test scenarios – everything go haywire if test schedule goes for a big deviation thereby disturbing the complete timelines of project. Definitely there should be no shortcuts taken for testing of a product thereby creating leakages that could lead to disaster at a later stage, but also important to allocate sufficient time for testing. Putting pressure on testing to finish it in time or rather before time because development plan got overshoot, is not a justifying phenomenon for product or customer.
There are many instances when testing goes for exceptions. In those cases the final test report submitted to development team must clearly state the deviations taken in the test plan along with appropriate reasons, and anticipated shortfall in coverage of testing. Someone in the Risk Management team must look at this report very carefully and find out the risks arising out of it. A proper mitigation plan needs to be chalked out depending on the risks and the severity arising out of these risks.
At times development team might have a confusion over a bug reported and/or they might not be able to simulate the same bug. Test team’s role becomes important in these cases to explain the same to development team for such reported bugs.
A comprehensive and detailed test report preparation during test phase of a newly developed product as mentioned in an earlier post here, makes a lot of sense in ensuring availability of light at the end of tunnel names as project management. Each phase of a project right since its inception is like a tunnel where at the beginning of your journey of that phase, you are never 100% confident for its timely and accurate closure. After all, projects, for years, have been a great topic of discussion and there is no company in the world that can claim this figure of 100% success in all their projects. There are always a number of hidden and visible threats to a project that could fall in the bucket of anticipated ones, or the ones emerging as a shocking surprise at any moment of time during project management.
Each test case must be given an equal amount of attention and the recording of results of test cases and test scenarios is quite important. All test cases do not result positive and same is true for vice versa. Hence it becomes important to record flaws encountered in the Bug Report in a clear and sensible manner so that least amount of time is spent by development team on understanding the bug and more time goes into fixing of bugs. At times, test team, in an attempt to show bigger count of bugs in their test report (so as to reflect higher amount of efforts gone in testing, which obviously is a misconcept) record multiple bugs for the same error thereby duplicating the reporting of bugs. A thorough inspection of Bugs Report is therefore important before handing it over to development team for fixing of bugs.
It is important to ensure completeness of testing for any new product built based on the customer’s business requirements. These business requirements become the basic source for defining development requirements and subsequently testing requirements. Testing is as important phase of any project as the development. In fact every phase of a project in project management has serious impact on any next phase of the project. Based on business requirements and subsequent logic being built in the application by development team, Test Team prepares test cases to ensure complete coverage of testing of the product. These test cases have to be extensive, exhaustive and meaningful. Test environment, test bed and testing strategy have to be strong enough to ensure meeting of customer needs as per customer’s expectations and not as per development team’s wishes.
Any changes happening in the code during or after completion of testing, which could derive out of various reasons, must ensure retesting and that too in exhaustive manner, without bothering about the change in logic is small or at a large scale. For this purpose it makes a lot of sense that development and testing go hand in hand till the product ripens to its final shape and becomes ready for deployment. Test scenarios have to be properly aligned with the exhaustive test cases built. Equally important is to observe the pass and fail result of each test case. A small gap here could cause a big trouble later.
That is why documentation and recording is necessary. It becomes handy at a later stage too for reference purposes, as and when any need arises to refer to it.
There are many ways to ensure complete coverage of software testing as discussing in my earlier post here. Let us revisit those ways and introspect a little more on the same. A careful inspection and selection of activities is a must to ensure adherence of process, procedures, policies, methodologies and completeness of testing of any new product during its built or after its built. Or it could be equally important for a newer version of an existing built that has already been released to customer(s). First and foremost is to ensure complete understanding of business/ customer requirements and then the business logic built in the product to cater to these needs. A gap in understanding of these requirements and subsequent in slippage in complete coverage of product testing could lead to a big disaster post release of the product not only in terms of money and reputation but also in terms of acquiring new business or keep holding the existing ones.
Documentation here has a bigger role in terms of – first, drafting these requirements in a crisp elaborating manner, and second, getting a sign off from responsible authority from customer. Engagement of quality team right at this stage ensure smooth closure of later stages of the project. While development team meets to discuss these requirements to draft out their development charter, plan and broad level design. The requirement document must be given as an additional copy to testing team so that they find out points of discussion for any clarity required from analysts or customer. It makes sense obviously as it is the testing team that gets into the shoe of customer to see the behavior, flow and functionality built. As a development charter and plan is built, a similar charter and plan is important for testing. Test strategy is an integral part of this. Test Methodology, test schedule and requirement of testing tools needs come out of it that define the scope of testing and building of test cases.