Most of the times the software delays are because of no proper requirements are gathered. Reasons of this could be many like lack of business knowledge of Requirement Gathering Team leaders, lack of experience, inappropriate allocation of time, wrong choice of customer representatives for understanding of business process and requirements and so on. In such cases the level of documentation remains below standards howsoever good may the expertise in documentation be.
Documentation of requirements apparently may look very systematic and structured in first go but once project teams start working for development and testing etc. they start finding out so many gaps and holes in the document showcasing a bumpy road ahead calling for repeated sessions of business understanding from customer and rebuilding of documentation.
Biggest fear in such cases is that if this stage crosses development and testing phase without any hiccups, it definitely does not ensure a healthy situation ahead. Rather it ensures that a volcano or tsunami was in the making during earlier stages is definitely about to erupt or break out soon during rest of the stages. And it could happen anytime.
UAT and implementation stages are most vulnerable stages in such situations where the hidden volcano bursts out when customer business process owner shouts out a flaw in software built to address to their business requirements. Those hidden major gaps unaddressed properly during Requirement Gathering Phase now spell out wounds badly on project.
That is why most of us agree that the most crucial phase of any project is Requirement Gathering Phase. If this phase is not addressed to in a micro level analysis manner, it may cause harm later to project, teams and managements.
Best way would be to vet and validate user requirements twice or even thrice spending a little time extra in beginning rather than asking for a higher amount of critical risks at a later stage.
How many of us will agree that whether it is project development team, testing team or implementation team, the title line applies to all. On road we all sort of people. People who are so disciplined that they never violate any traffic rules can be termed as category one people.
People who when under surveillance demonstrate themselves as the best followers of rules though in actual they may not be. Such people can be categorized in second slot. And then the next category is of people who are inherently violators of rules without caring about anyone or anything and these can be called as number three category people.
Similar are the team members in any team. It is better to have more number of team members who are self disciplined and systematic under all circumstances without bothering to demonstrate it to anybody. Higher number of such members in a team will definitely help in inculcating the similar culture among other members falling in the other two categories. Higher number of category two and three in any team will always call for higher amount of defects, bugs or shortfalls in their output thereby calling for more rework and more reviews.
And with focus shifting from project progress to addressing of reworks and reviews. This is definitely not a healthy position for a project and neither for the teams responsible for project. Another drawback under such circumstances is that those in the team who are otherwise consistent good performers start losing their focus and energy as they do not feel things going in the right direction. This in turn becomes another showstopper in overall project progress thereby deviating whole project to wrong direction.
Test Plan is a basic and fundamental document of quality department. It is project based document so has to be made afresh for each new project. It has not to be very thick document so that it does not become just a record purpose document in office in your drawer or shelf. On the other hand it should not be too thin to lose its sanctity and purpose.
Test Plan needs to be prepared as soon as the requirements study is completed and signed off from customer. Once requirements are there clearly on the table two parallel activities start immediately after respective team’s formation. Design and development team can start working on system design, database design, coding structure and so on.
Sideways based on the finalized requirements Quality department can start working on test plan. Test plan is a broader coverage of product testing at various stated that includes detail of various test methodologies and variants to be adopted or discarded and their basis of selection or rejection.
All testing may not be relevant for all sorts of products. Depending on whether it is server client architecture or web based product (which is more popular these days), test plan is prepared.
Usually it is QA head or lead who should be the owner of this document. Test plan clearly states various testing activities to be performed during various stages of product development. These activities have to be assigned to various team members along with a stipulated target date set to complete those respective tasks/ activities.
Quality Control as is evidently clear is a post facto exercise. It is something like finding faults or shortcomings in a product that has been built, manufactured or designed in its completeness. Drawback of QC is that it does nothing more than a post-mortem of the product. Whatever be the case, the number of defects identified in a product demand for exponential efforts thereby reducing margins, profits and time with an increase in input costs.
If effort estimations are calculated, the amount of efforts increase manifold with the development stage at which a defect is found in the product. Early stage defect identification calls for a minimal amount of efforts and will not have any substantial impact of delay in delivery. The later a bug or defect is identified, the worse it becomes for product, team and customer. It is quite clear that disassembling of a product for a defect rectification and then assembling it back to original always leave some gaps in terms of quality and productivity of that product.
The more number of times a product is fiddled with for fixing of bugs or defects more are the chances of it going downgraded in terms of quality and integrity.
And moreover QC or quality control generally is focussed only on end product, but pays least attention to the processes and procedures involved that drive product development. A very lenient or weak control on methodology, process and procedure of product development have higher risk of producing software with more number of bugs as compared to a situation otherwise.
There are ways to address the issues and there are ways to produce excuses for not doing certain set of jobs. The higher is the engagement of a process head in his/ her department’s day to day issues, the least are the chances of his becoming a Newton for his department or organization. A manager once was asked how he was available all the time with a sweet smile on his face seemingly having no tension and workload. His department was doing quite well as compared to other departments where the respective manager’s had higher amount of engagement in department affairs.
The manager replied with a smile on his face that he has three friends always to help in running his department perfectly well. Who were those three friends, he was asked back, that keep him happy all the time. He replied his friends are – empowerment, trust and well defined process.
The manager said his main focus remains more on timely results rather than scrutinizing of following process all the time for his team members. A steady flow of desired or planned results well in time speak well for process being in place. But that doesn’t mean that he never reviews processes. A frequency is set to review the processes in place and mostly it has to be an interactive session because feedback/ suggestion for improvement can come from any level.In between if there is any deviation in results, then also processes are reviewed.
Empowerment to subordinates is very important. Unnecessary questioning them time to time is not a good sign of a boss. Recruit sensible people under you, give them a leverage to settle down and then let them flow on their own.
Top sheet of a test plan must specify the project name, ID, detail etc. for which it is being prepared. At the bottom of cover page of a test plan do not forget to mention the creator’s name, usually it would be quality lead or head depending on the organization structure of quality department. Table of contents must segregate different important sections very clearly and precisely.
First constituent or component of a test plan would be Introduction. In introduction give a brief
summary of the product being tested
. Also outline the
functions at high level to be covered
. Next component would be objective and tasks. Objectives must be clear, crisp and bulleted. Tasks should be well defined, with target dates to achieve each one of them and assigned to whom.
In the next section define scope of testing, tactics to be followed, what is covered and what is not covered under the scope of testing. The next section is to be quite interesting, elaborative and can be termed as the heart of Test Plan. It is Testing Strategy. List out all types of testing you plan to cover, who will be conducting it, and what will be the methodology followed for each.
Then come two more important sections as Hardware Requirements and Environment Requirements. This information should basically come from the product head. Tester’s test bed preparation would solely depend on these specifications and therefore these specs should be as realistic as possible.
Next section would be about Test Schedule. This test schedule basically is a sub component of project schedule. Next to it would be Control Procedures which will take care of change requests procedure, problem reporting and solving procedure etc.
Next two sections will focus on Features to be Tested and Features not to be Tested. To avoid any ambiguity at a later stage of the project, specify very clearly these two sections. Next section takes care of Description of Resources involved in all above mentioned exercises with their roles and responsibilities.
Then comes the schedule of deliverables as far as testing is concerned. Mention all departments having backward and forward linkages to testing activities in the next section of Test Plan. In last three sections define Dependencies, Risks/ Assumptions and Tools list/ description.
Final section will contain the names of approvers that will include development, project heads along with any other heads concerned. It is important to keep everyone in sync throughout.
One fine day, Project Manager sitting in country X gets a call from his client in country Y. Customer’s Business Manager told Project Manager over the phone about their new requirement of over two dozen reports, the list of which he has just emailed. He requested project manger to go over the list in which he has clearly mentioned the detailed requirements for each report so that in case of any doubt project manager can get back to him. Next day morning, Project Manager ensured his customer’s Business Manager that requirements are clear to him and he will get the reports delivered in a stipulated timeframe.
There was no process in place for an instant recording of customer’s requirements in lack of which the things remained in the mailbox and mind of Project Manager only. Before he could take action on it and allocate it to his development team, he got engaged in certain other headaches and forgot to initiate this process. Gradually as few more days passed, this important mail from customer got buried over a pile of many other mails and lost its attention and visibility.
After more than the committed timeframe lapsed, there was a call from the same Business Manager to the same Project Manager asking about the status of reports. Project Manager was lost as it was more than a couple of months old story. He asked for sometime to get back to Business Manager, searched for that mail and was in a dilemma what to do as he had not taken any action on it.
He called his production team and thrashed over them over this issue. Production team was blank as nobody was aware about this requirement. In a state of emergency the reports were allocated in parts to half a dozen developers for finishing them in 2 days time. A commitment was given to customer that the reports shall be delivered within 2 days. For development of reports some were engaged in this project for the first time in order to tackle this emergency situation.
As expected, due to developers fresh to this project, shortage of time, lack of appropriate testing and unsystematic approach of Project Manager, the reports could not be delivered upto fourth committed date by which the customer was already losing its patience. And even the reports that were sent to the customer could not pass real business scenario due to wrong results produced.
Whom to blame? What lessons should be learnt? How to ensure this not be repeated again?
What Kind of Quality can you manage In your project if you don’t know well about your customer’s business and their expectations from the product your are going to build and deliver to cater to their business needs. Project management is very easy to perform as long as you have two close associates named ‘IGNORANCE’ and ‘LACK OF BUSINESS KNOWLEDGE’. But then the reward at the end of the project will be nothing but FAILURE.
Customer running his business successfully would decide about going for any software with a clear cut intention in his mind. The intention would be nothing but to streamline his business, ease his employees and associates on their efforts in managing and running their respective activities related to business.
Unless and until a project manager understands the intricacies of business and technology in regards to project development, he would not be able to do any justice to either project or to his role. Some of the indications in such a scenario would be as below:
2. He will be a dummy project manager on top of various teams without contributing much at team and individual levels. Things will be happening on their own thereby decreasing the possibility of success chances of such project.
3. Management would not be having a full confidence in such a project manager. Rather somebody else in the team would be performing his role thereby confiding with management in critical matters.
4. He himself would not be quite confident and satisfied even being howsoever smart to hide out his weaknesses.
Logically in such a scenario, if Project Manager feels he has reached to this extent, he must either upgrade himself overnight else quit. it appears to be an extreme situation which should be avoided at any cost.
Three major components that lie in people who build a strong product meeting business requirements and user’s expectations could be termed as – business knowledge, product knowledge and quality sense.
Quality as such is a subjective term unless you define it, measure it, drive it, sustain it and improve it. Let us see what all this means in simple terms:
Define it: Defining of your quality is as important as defining your project. This primarily should cover your broad vision of quality parameters defined for project, process of monitoring and measurement and course of actions in case of deviations fro set parameters.
Measure it: Defining is very easy though not simple but adherence or sustained adherence is difficult. Adhering to what is decided is painful though not for everyone in the loop. Without adherence there can be no monitoring and measuring. What was decided, what is happening in actual, how vast is deviation, what is the root cause of deviation and how to ensure that the same causes do not occur again to create deviations.
Drive it: Defining and measuring for one time is easier as compared to having a clear cut drive in the whole group or organization towards common goals related to quality approach. Unless and until things go into the blood of each and every individual, quality can be achieved on the basis of few.
Sustain it: People come and go, get shuffled in various groups, advance in career with change in responsibilities and perspectives; but quality drive is something that needs to be sustained as a culture in the organization. It is not time bound or limited to certain set of people of projects. It is an organizational goal that needs to be driven, groomed and flourished to a level where difficult things seem simpler to everyone.
Improve it: Nothing is ultimate, supreme, and best in this world. There is always a scope of improvement and excelling in any process of the organization. A regular monitoring, metrics, follow up and analysis process provides ample scope of improvement if taken seriously.
Most of the project managers would agree that it is not practically possible to adhere to written procedures and processes by hundred percent under all circumstances. Even if based on situational analysis and past projects experience, those procedures are updated on a regular basis, every new project brings out a new situation not met with so far in previous ones. For that reason most of the project managers agree to the point that it is important to be proactive and innovative during any project lifecycle.
Though life doesn’t stop even if a project manager strictly follows written procedures without any deviation provided those procedures are so well written and are matured enough to manage the complete project lifecycle. A project manager working in this pattern does nothing bad and it does not call for his project failure. Rather it is always better to follow well defined procedures in disciplined manner rather than defining them and not following them thereby making a mockery of them.
But it is well proven and experienced that project managers who have these two assets named proactive approach and innovation, and in case they fully utilize these assets, it is always giving them an extra edge regarding project progress and success. It is interesting to note that in a survey done among project managers, percentage was enormously high who agreed that being innovative is very important for winning over customer during a project. But the percentage fell drastically when it was asked how many of them actually deviate from their well defined procedures to explore an innovative approach thereby winning over a situation when it has come to a halt.
If you don’t know where you want to go, in which direction, to what destination; probably your sitting on wheels is useless. Equally harmful is if there is somebody else sitting on wheels and you are sitting beside taking charge of directing him to reach the right destination. If you have taken that charge and lack information about starting point, directions, road conditions, distance, how much petrol is there in the vehicle, where are you heading for; your motive is as useless as other person’s.
Same is applicable to Project Lifecycle. Whether you are a project manager or quality head or both; gasping about any of the relevant information or knowledge will drive your project to a disaster rather than a happy ending. One important question that arises many times is who actually drives a project. Is it the project manager, or the quality section, or management, or customer, or who? Is it really dependant on a single personality, somebody like a project manager, or is it driven by the whole project group comprising of different teams.
Ideally a project should not feel a single jerk with the entry of exit of any person on the train, how so important that person be. But in practical it really matters if the project manager vanishes for a substantial period during an important phase of a project. Something more to analyse is – are all moments during project lifecycle equally critical and crucial. Answer would be – NO.
If all phases and activities are equally critical then it could indicate a low maturity level of the organization as a whole who is managing this project. As the maturity graph goes upwards the management of different phases of a project also becomes easier.
Project base hiring of people or project based outsourcing of job is all dependent on project type and product life. An existing or a new customer may come out with a unique requirement requiring altogether different skill set other than existing in the organization. Depending on product and its fulfilment of business requirement, it will decide in due course whether the organization needs to hire a new breed of employees expert in those skill set or outsource this unique requirement development to a third party without bothering about the whole recruitment and retaining process.
If it is decided to develop the product in-house, probably as an alternative, existing bunch of some sharp employees can be thought of to be trained on this different technology to cater to customer’s business requirements. What factors will encourage on organization to outsource the job will depend on certain circumstances or factors. Conversely organization may go out for a new team building which also will depend on a set of circumstances and situations.
Factors defining outsourcing could be listed as below:
2. If the product is not too repetitive in demand from other customers
3. If organization has a good command and experience on outsourcing and getting the best output based on their past record
4. If there is already a shortage of high skilled persons in organization
5. If all highly skilled persons are already engaged in other critical projects and cannot be spared out for this new project
The factors to decide on doing it in-house by means of hiring new people or development of existing people will be more or less vice versa of points listed above.
There are three types of companies that exist in today’s world. First is having a great work culture but less growth prospects. Second type has good growth prospects but work culture may not be too attractive. Third type has both at its best. The fourth type with no work culture and no growth prospects will find it difficult to survive and hence no point in discussing those companies mushrooming for short tenure and then vanishing out of blue all of a sudden.
Logically it doesn’t make sense to say that an organization has least or no scope of growth but has a great work culture. And the same holds truth for vice versa too. That is it would be a misnomer to declare an organization as having great growth prospects but having worse work culture. Practically it may hold truth as exceptions and such companies do exist. But most of the organizations worldwide understand that if a good work culture has to be sustained for long, there has to be good growth prospects for its employees and vice versa holds equally weightage that an organization having a great scope of growth for its employees has to have a good work culture too.
The same holds truth for software projects too and the teams involved in those projects. If a good work culture is maintained during project lifecycle, chances of success of project increase. More successful projects means more growth prospects. The chain doesn’t stop here. More growth will automatically enhance the work culture further. And the same loop keeps going on and on.
Size and age of an organization does matter in certain key areas related to employee’s retention, growth, satisfaction, attraction for new good candidates in time of requirement of recruitment and so on. Though these two are not the only factors that matter for above points mentioned here but definitely these two points play a considerable role in that. In software industry there are two ways of running your organization. For example for development of a one time different technology product you will have two options – one, to recruit skilled developers and get that product developed in-house; second – outsource it to another company having matching skill set.
Recruitment or outsourcing is a crucial matter and need a deep introspection within an organization before arriving at any beneficial conclusion. In fact based on various types of projects that are being carried out within the organization, a proper policy can be put in place clearly defining a demarcation in case of any job to be carried out – whether by route of recruitment or by an alternative course of action of outsourcing to a third party.
A diversified short timed project requiring very different skill set than that exists in the organization will definitely call for frustration among team recruited for that project at the later stage after the project is over. The team, howsoever talented will find least scope thereafter to demonstrate their skills and hence will have lesser scope of growth as compared to the teams involved in regular projects in the organization.
Best way is to outsource such jobs but even if some high skilled manpower have been recruited they can be well rotated in other skill areas after the completion of their current one time project. Some organizations do recruit under those circumstances on project basis something like a contract. The person hired will stay in the organization as long as the project continues. Renewal of contract will certainly depend on similar project’s existence in the organization or other skill set in the hired person so that if being extraordinary may be absorbed in other projects.
Recruitment is something that always keep HR department engaged in any software company of any size, location or standard. Employee turnover is a continuous pain for that matter for HR that compels HR department to keep their database abreast based on the inputs from development and deployment departments. A requirement raised last time is of no value as compared to the current value in any department or organization.
Hr department is required to be well equipped with the data regarding current level of all employees existing in the organization, their profile, roles and responsibilities, experience, growth pattern etc. Not only that, they need to be proactive in terms of estimating appropriately about the employee behaviour on the basis of which they can very well judge about the commitment level of any employee towards his/ her job and/ or organization. The profile of an employee who has never spent more than two years in any organization in past will call for an alarm when his/ her tenure is reaching to that level in your organization.
HR needs to have a good network in terms of social networking site, media, some active relevant group networks, online and offline job portals etc. For that sake an internal survey about existing employee’s acquaintances becomes handy if maintained to initiate an internal referral recruitment process in case of a vacancy. Some organizations do not mind rewarding a nominal amount to referee.
Many organizations go for next level of maturity when they start rotating their employees internally on a regular basis. That acts as a two level benefit for organization in return. One – no situation becomes too critical in case of any key person’s exit as there is always a backup for that profile and second – it increases the confidence level of employees by gaining exposure, experience and learning in areas where they need improvement.
While standard process and procedures in place by project management committee at most times may overcome any hiccups but at times even a small disruption during project may tend to impede project progress.
During these testing times project committee may feel a need of the revision of existing processes in place so as to revaluate them rigorously to ensure project continuity in such happenings in future. Purpose of review meetings should always focus on strengthening of process and procedures related to project management methodology.
One of the prime purpose of a project review meeting is to ensure that overall progress of project has improved, which can be achieved by participation of maximum number of project stakeholders in such meetings.
Though time is important but equally important is wisely spend of time on important project issues during these meetings. Some burning issues may require extra review and extra spend of time which should not act as a constraint. Every review meeting should act as a catalyst for project and its progress.
Improvement, as wisely said, has no end. Improvement is a continuous process and at any stage of maturity there is always a scope of improvement. When I say maturity, it could be in terms of maturity level of an organization or maturity of your process and procedures for project management. As stated in my previous post, there is no need of panicking in case of any exit of any senior person taking care of project during running of a project.
Though it becomes more crucial if the exit happens at a later stage of a project but if there is some set of standard process and procedures in place, the situation can be managed with a small addition of attention.
During any software project, resignation by a project manager really becomes a regrettable position for whole organization. Someone is immediately required to react towards working to coordinate matters so as to designate his successor as the new project manager (ad-hoc or permanent) at the earliest possible time. No project can afford any discontinuity in its progress.
Irrespective of circumstances, there would be a number of processes running simultaneously in different phases of the ongoing project within same or different teams. The reviews and discussions need to take place on a regular basis under circumstances or even under all circumstances.
The approach of reviewing of project, on a regular basis, need to be carried out in an uninterrupted manner. This is important so that teams working on project do not lose their rhythm and momentum at any point of time. Segregation of tasks that need immediate attention in terms of technical assistance, extra resource, revision in targets, or anything else from the tasks going smoothly with no extra punch required is quite important.
Especially having arisen form such circumstances, there is truly an enormous significance in the process itself in which further directions are decided in view of the running project. This could be achieved through streamlining of running procedures that can be achieved well via smart documentation, regular reviews and proper distribution of responsibilities.
Equal engagement of all team members in project is important so as so is their involvement in reviews rather than discussing about project by a few top chairs behind closed doors.
Prime skill that a business or an organization requires in today’s scenario is a new way of thinking for their existing set of problems. The same thing is terms in many ways – a new way of thinking, an innovative thinking, an out of box thinking, or thinking beyond. Barriers are not set in problems or their solutions, barriers lie in our minds.
The same set of problems if given to different individuals is handled in different ways. This is the same way organizations work too. A project team can also be termed as a mini organization as a sub set of their overall organization.
No individual, no team, and for that sake no organization carry out their operations without facing problems. Recurring problems act as a pain in the neck of any individual, team or organization. It is merely a foolishness to keep getting recurring problems and wasting energies to fight them out again and again.
Energies that should go into new growth charters get consumed into removing the hurdles in path of that growth, which is not a good sign. It becomes daunting for project thereby leading it to a death trap rather than providing it with a spacke to flourish and move towards success flawlessly.
Every organization strives for increase in productivity and profit which is the ultimate goal and a reason of their prime existence. To achieve these two most trusted drivers are better quality and better service to the customer. Sustenance of good quality and good product does not suffice the purpose in today’s business scenario. The word ‘good’ needs to be replaced with ‘better’.
First delivery of a good product or service becomes bare minimum expectation for your customer the next time. Next time delivery of service of product has always to be something extra than the previous delivery in your project.
Every organization has a maturity level. This level defines or controls a level of that organization to acquire a capability of solving problems. No organization at any level of maturity is strong enough to tackle all problems, every organization faces two sets of problems in their agenda – one that are solved immediately for which the organization is capable enough to manage, control and solve; another set of problems is that organization is not able to solve easily.
To manage such ‘not too easy to solve problems’ the organization needs to be innovative, daring and bold enough to carve out new path to find out an optimum solution to such problems. The same applies to each of the teams existing in that organization which further applies to each member of those teams.
Maturity level or capability of solving higher level of problems in an organization is nothing but the collective maturity level of each individual of that organization. After all organization is nothing but a group of teams comprising of individual members.
Merely on the basis of a strong management with high maturity level, an organization cannot boast of having a high maturity level. Every task is not done by the top management but most of it goes further down to an individual level in different teams.
Therefore, the most valuable asset of any organization is the minds of their employees. This is where the role of top management’s role comes into picture – to harness, master, control, drive and empower these individuals.
A lot of juggle has to be an expertise area of any project manager during managing a project. Project without specifications has no meaning. But even if there are well defined specifications which are not adhered to also becomes as meaningless as running a project without specifications.
Specifications are required to be defined for any project. Specifications in terms of project requirements, customer and business needs, team formation, technical requirements, budgets, targets and milestones, and so on. Once these specifications are there in place, they need to be adhered to ethically without any fail or deviation.
Deviations do happen in any project and nothing goes as straight as planned or thought of. There have to be specifications on how to manage those deviations. A proper risk assessment and management has to be in place to manage change, deviations and failures.
This all comes under compliance. What if your customer gets something weirdly different from what he expected from the product you built? How frequently in your project do you face a blush off situation in front of your customer for a large amount of variance in inputs and outputs consistency as compared to the specifications?
Testing coverage specifications is another area that can overcome all these sort of blush off situations. An ad-hoc testing is always a blunder as compared to a well planned testing taking into account the complete coverage of product in question. Testing coverage is nothing but quantification of the areas of system to be tested with how much rigorousness. Serious areas of product having high impact on customer business need to be tested more thoroughly with no scope of leverage.
a perdurable a day, helps you sleep, work and play
Your project dashboard is very important during project management and equally important is its visibility. Purpose of dashboard is not merely for the sake of its existence. Purpose is much more beyond its purpose of merely existence.
Your dashboard must be a report card of your project at each stage of the project. It should be showing metrics of your project performance highlighting the red areas very clearly that need immediate attention. Project dashboard also must have a capability of drawing performance trends – activity wise, individual wise, task wise and team wise.
Take care that your dashboard must update regularly, should run faster, and quicker. It needs to be maintained less expensively with least complexity involved in maintaining and updating it. Don’t forget to have a count of failures on your dashboard.
Technical and functional team’s confidence in any ongoing project depends heavily on their past performance and performance trends in previously closed project and also in the closed tasks of the current project.
A good performance trend in the past always acts as a booster in their morale and confidence at any moment of time. Habit of failures goes less that way thereby mitigating any upcoming risks in a project.
Adopt smart and innovative way of decision making during project management to enhance your team’s capability. Put your team in a position where each team member is dedicated towards a rapid response mechanism. At each step of your project check out the factors that may lead to project interruptions due to any level of functional and performance issues.
To manage your projects across their lifecycles, a project manager needs to learn and adopt a well managed and integrated project, demand and portfolio management methodology.
Is QA, or for that sake QC, an expense or an income for an organization engaged in software development commercially. A step further would be to ask if software development itself is an expense or an income for the same organization. No software is built for charity purposes by any organization for a longer period.
It can be done only in a hypothetical situation for an organization having a regular funding from some other source or another group of the organization. Otherwise an organization having infrastructure and people in place to run a business cannot afford to keep developing software applications without any sales targets with stipulated time frame in mind.
Coming back to our point if QA/ QC costs being incurred for software application development and trying to find out how these expenses are accommodated. To ensure that the right product gets launched in market with least negative impact on organization’s reputation due to application failure, its thorough testing becomes prime goal for any organization prior to its launch in the market. Formidable reputation jerks at a later stage after launch of product in the market cause much severe damage as compared to the expenses incurred well in time to ensure perfect quality of a product before it is launched in the market.
If quality of a product is achieved by any organization for their product to be launched in the market as a signal of obligation to their customers, it is a fake call. It is actually for their own sake that organization spends on ensuring best quality product getting developed in their process of development lifecycle.
Costing of a product must be done accordingly to accommodate expenses incurred on quality of product during development and deployment phases.
A good quality product always brings back hike in reputation of organization and increase in order booking from further new customers. It is overall quality of product that returns back higher organizational income in terms of high volume sales and more orders for their loyal customers. Trust and loyalty go hand in hand. Organizations that are able to build good amount of trust with their customers get their loyalty in return. This all pays in manifold that sometimes goes unnoticed by the organizations.
If there is a choice between mitigation of expense of running Quality department in your software development centre versus risk of service interruptions; later is always carrying a higher amount of risk as compared to former. Spending few extra bucks on quality to ensure an extra amount of product stability is always beneficial over the later stage service interruptions caused by higher volume of bugs getting encountered thereby causing more frustration at customer end.
Let the pain be shared internally before the launch of your software than getting the drums beaten outside by your customer after its launch and deployment.
Well planned initiatives related to achieving higher quality of product during development in an organized manner is always better. This can be achieved well with the help of continuous micro level monitoring and inspection of product during its development to ensure desired integration and quality of product. This will automatically reduce the risk of service and product interruptions at later stage after and during product deployment.
One of the best ways to reduce product downtime is to launch a bug free product. More bug encountered at later stage after product completion and its deployment at customer site will demand large volume of bug fixing, testing, re-testing and down time. This will automatically reduce downtime costs thereby giving a boost to developer and tester productivity.
Proper synchronization among your team resources into a test that enables you to delivers best quality product is always wise to do right from the beginning of project. This will help organization in getting development, testing, and other teams to work together towards a highly reliable product.
In today’s scenario there is no life on this earth without its dependency on any software in one way or the other in professional or personal front. This is what technology and its advancement does, it makes us more dependent on it by providing us more accuracy, comfort and satisfaction. We do something only because we have some trust in it towards the desired results. Same thing happens with our customer also.
When customer buys or orders for a software to us, there is a essence of trust and loyalty hidden behind it in wake of a timely solution that works properly, accurately thereby giving a high level of comfort to customer.
Software that helps customer in getting desired business results definitely increases their satisfaction level. Some points need to be followed while building software for your customer that can be listed as below:
2. It may happen that something unique for the first time is being developed for a specific customer need. But that may not be the case always. In case of horizontal deployment of your software to a new customer, ensure to produce a detailed list of your installation of the same product. Claiming all installations as 100% successful would be something easy to raise customer’s eyebrows. Start with your most successful installations depicting most satisfied customers but do mention some failed installations and their reasons so as to raise an alarm in advance.
3. Ensure to understand your actual efforts involved before submitting a commercial proposal to your customer. Understand customer business and their requirement/ expectations from the software you have to build/ supply very clearly before any getting into any commitments. Ensure about the flexibility limits required in the software as per customer’s expectation. Understand the difference between plasticity and elasticity.
4. Listening to your customer about their business process, pains and expectations is more important than boasting about your product and its capabilities. Before you understand first what customer expects or address to his which business pains, your songs may be irrelevant and may go unheard totally.
5. Demonstrate by way of doing. A well designed presentation about your product and its capabilities may win customer’s hearts but will never be able to run their business and address to their requirements. That can be achieved only by way of software application.
With technology changing every minute, it looks as if we have covered galaxies of distance in last decade or so in terms of advancement in development tools and features. Definitely hardware need to be advanced accordingly to support the resource hungry features built in development tools. Specializations are a defining factor in today’s software development world.
It is not that any development tool will fit in for any software requirement from customer. It requires a complete mapping of hardware, software and peopleware in current scenario to arrive at an optimum solution heading to a win-win situation.
To develop specific software, there need to be a right mix of technical team members. Database administration, database configuration, software development, technical documentation, software testing, software implementation, database and application installation, customer training, customer support and so on are all a mini project in their own spheres.
All these mini projects size up together to build a complete project. All projects are divided into different phases. All phases cannot be started or finished together. Some would be possible to run parallel while others would be sequential in nature. For example software development, server configuration, database configuration, technical documentation can all be started together. While training to customer cannot be imparted without actual software to be implemented at customer site be in place.
Team formation, team coordination, monitoring, follow ups, target setting become prime important to achieve project success and build a strong bonding within teams, with management and with customer.
During different stages of project management, training is an important tool that is used to gain best results of the effort put in project. Be it customer requirements, development, quality, deployment or support; training remains integral part of each phase of project management.
Training contents and appropriate tool/ methodology to be adopted for training depends on various factors such as:
2. depth of subject,
3. knowledge of speaker,
4. volume of audience,
5. time allocated for holding training session,
6. mix of audience
7. and experience of trainer.
There could be many more factors too as per different trainers around the globe.
Methodology to be adopted for a particular training depends on above factors. Various methodologies commonly used in a structured manner for imparting effective training can be listed as below:
2. Lecture: /lecture and presentation are different in the way of more emphasis on speech and by way of writing on his own by trainer during the training on a black or white board to keep his audience alert and interactive.
3. Group Work: This is something like a workshop where learning is done by way of doing in an actual manner.
4. Case Studies: A very non interactive way of training where material is handed over to the trainees to read and learn from there.
5. Feedback Session: This is not actually a complete training methodology but a post training session to gather feedback regarding the training imparted to trainees.
Running a business is nothing but a composition of certain processes in place taking care of all elements important for the purpose of business. Growth of business happens with maturity of processes in place. It does not mean that to run a high level business you required complex processes. Even with the help of simply drawn processes you can establish a high level business. In fact sometimes more complex processes defeat the reason of running a business and become a cause of disaster of business.
To control well defined processes in place, a top level body is called in the organization that is termed as management. Management has to ensure two prime and foremost factors to establish and run a business for long term. First objective is to have well established processes in place and second but more important factor is to ensure those processes being followed all across the board. More control on business processes makes more efficient management; and vice versa. To have good processes in place and to ensure their adherence you need a good management. On the other hand to have a good and efficiently result oriented management you need good processes in place.
Effective and efficient go hand in hand that way. More effective business processes result in more efficient management and organization. More efficient management will always seek more effective business processes taking into consideration some world class benchmarks to set their goals for further optimization. As it is well said – improvement is a never ending process, the same holds truth for business process too. No business process is optimum or 100% efficient. It always has some scope of improvement.
As a new project gets into project initiation phase a formal project strategy is important to bring on board. Team size, team members, financials, operational and all other planning need to be worked out based on project strategy. It clearly signifies that a wrong strategy would lead to wrong direction altogether heading to a big mishap at a later stage.
Team size and team members’ selection is something that needs a very in-depth analysis before finalization of the two sections. This is important because all other factors like capital investments, operational cost and planning etc would depend at large on these two sections.
Although team size and composition changes in between during different phases of a project. But the change is mostly not major one so as to impact highly on initially planned numbers.
Generally organizations that perform at an optimal scale like to analyze multiple scenarios with the help of latest technologies so as to have a smooth ride at a later stage. Different scenarios and their results if analyzed initially help with a quick and rapid change at a later stage with a change in scenario.
For a multiple location implementation in an organization, it is recommended that to do it in a smarter way, an enterprise wide integration planning process right from the beginning would help in a bigger way thereby decreasing start up and deployment costs. An integrated way of planning, budgeting and forecasting helps a lot.
Budget and plan forecasts may be avoided to go haywire at a later stage if uncertainty is removed with the help of latest technologies and large number of scenario modelling.
Total involvement is something which is not visibly tangible but there are ways to do so thereby spearheading any project towards higher rate of success. For example same software being implemented in different organizations has different rate of success. At some place it may be a very successful implementation leading to very high rate of drawing of targeted results while at other place the whole implementation may become a disastrous failure.
Only differentiating factor is ‘total involvement that makes a big difference of success and failure of the same product implementation at two different locations. In between the two – hundred percent success and total failure – lies different success (or failure) rates depending on the degree of ‘total involvement’.
On top of different level of teams in any project management process, there need be a team named as Leadership team on top of all teams. This team may comprise of members from all other teams or may have a different set of members altogether. But the main task of this team remains same – spearheading all others by being fully charged and motivated all the time.
A transparent accountability process also plays a major role during project management during all phases especially implementation phase. Exact deliverables during implementation phase must be clearly defined so as to treat it as a checklist for both teams. Deliverables break down further to micro deliverables that lead to each team’s charter, customer engagement, scorecards, process mapping etc.
Customer feedback is another important tool that not only keeps you aware and alert but also tied up tightly with customer. Just a word of caution here is that never let feedback be too formal or too informal. Let it be realistic and transparent rather than just a formality activity.
Change is generally not welcomed in any system and is treated as problem. Change management is full of obstacles some foreseen and some unforeseen somewhat similar in nature as that of project management. Project manager need to overcome a number of obstacles and hurdles while project development and implementation. Software implementation is also a part of change management as it requires a number of changes in the organizational culture and its business process.
Ownership, commitment, motivation are three major obstacles that come in way of project manager in terms of the organization where project implementation takes place. Everyone in organization welcomes new software to be implemented for easing out business process functioning but there are equal intensity of resistance too which is sometimes not visible openly though has a full existence in place.
Changes in terms of technical environment are easier to impart during product implementation across an organization as compared to the culture changes. Total involvement with a top down approach works better in any implementations as compared to a bottoms up approach where top management is not engaged in the process.
‘Learning by way of doing’ and ‘Demonstrating by way of doing’ are two important tools for managers to confide their teams during an implementation phase. Just do and demonstrate rather than demanding the same set of action from employees down the line.
This way of implementation increases trust factor across not only among different levels of management and other staff but also in the product being implemented. That way it automatically increases the level of commitment and engagement.
A good writer is one who pays equal weightage to proof reading or editing of his work besides being focussed on content quality and writing style. For every new work that a good writer produces, he doesn’t mind spending some more time on it and getting some different opinion on what he has written. The great author Hemingway always had his books edited and proofread before giving it a final nod for publishing.
Similar approach must be inculcated in a tester too as far as bug reporting is concerned. The way a bug is reported may not be understood or interpreted in the same manner by a different set of eyes reading it with a different frame of mind.
In bug report, a tester knows clearly what is intended to be reported from his end. He might explain about a bug thinking it as the best way to communicate his purpose. A developer on the other hand as a different entity may understand differently to what tester intended to communicate and thus may take a different meaning that may lead bug fixing to a different direction.
Definitely in case of a doubt, when developer seeks clarification from tester about a bug, things would get clearer removing out all gaps in intention of report and its understanding. Bug reporting is always an interactive process. Logically after reporting a bug a tester must leave report as it is without sending it to development team. After sometime tester must come back on the same report that he left, read it as a developer would read it. This way of editing with a virtual different pair of eyes a tester would be able to seal any leaks in his bug report.
Rereading and editing of report is in no way a waste of time or effort comparing it with the time or efforts required later in wake of unclearly reported bugs. In a broader way, it can be treated as a quality check of bug report.
Presence of some particular teammates in their team makes a big difference in terms of team momentum, tempo, confidence and quality of delivery along with high rate of delivery. Some team members are self starters and self goers while others need ignition from others. But there is a rare set of team members who act as team starters and team goers. They have a tendency of working with a wide angle rather than focussing on just themselves.
Those team members have an extra spark in them. They have some typical properties in them that differentiate them from others in the team.
These typical features can be listed as below:
2. Self starters.
3. High achievers.
4. Target Oriented.
5. Consistent winners.
6. Challenge acceptors.
7. Exemplary for others in the team.
10. Down to earth.
Everything does not go as per plan in any project but there are ways to put things right back on track. It is these sort of teammates that make it happen. Such teammates are very strong building blocks for the team. As long as they are there in the team, team keeps going as a single unit producing the desired results in right manner.
Lean and Agile are two keywords being widely used nowadays in most of corporate world engaged in production or development work across the globe. Let us see how these two terms fit in quality assurance and control of software development in software industry. Main focus of Lean lies on flow of development or production of software whereas Agile talks about initiatives taken in adapting change. The difference holds valid for both scenarios whether we talk about software agility or business agility.
In a better perspective if we see, when we talk of focusing on flow, it implies to an effort to inculcate an ability to adapt to a change. On the other hand the purpose of focusing adaptively to responsiveness requires an in-depth analysis and focus on flow. So in a way both are tightly integrated to each other even being two separate entities and may lead to a similar end result.
Agile software development methodology stresses more on highly matured teams. So much so highly matured that there is a very high level of trust between management and teams. The management empowers teams to an extent that none of the management personnel interferes or questions the functioning of teams. Teams in turn give a very high level of transparency to keep noticing team’s regular measurable results.
Most of advanced organizations engaged in software development business prefer to adopt agile methodologies to reap benefits of it in real sense. Lean is mostly adopted in a manufacturing environment so as to gain scaling across enterprise to optimize value stream.
Focus of Lean is on PROCESS more than PEOPLE whereas Agile gives precedence to PEOPLE over PROCESS and tools. Lean is a method of scrutiny of process on a regular basis. Purpose of Lean is to eliminate waste so as to deliver efficiently and quickly.
An Organization and project management cannot be treated as two separate parallel entities in Lean environment. If one is treated as a whole system, another becomes a subset of it. Waste created in organization cannot be treated as a non impacting factor on project teams. Project management teams have to be a component of organization structure similar to HR, finance and others. That way organization as a complete system has to be quite interactive with the functioning process of other sub systems.
There would be two approaches for this whole system and its sub system architecture. One would be top down approach while other is bottoms up. As is clear from the nomenclature whatever approach is adopted, there has to be a clear cut linkage between the whole system and its components functioning as its sub entities.
When forming an organizational structure, all levels must be engaged into it so as to impart or distribute ownership across the board in a proper fashion. Preferably start designing with a bottom up approach, taking into account the core anchor team in the process engaged with customer directly in any manner.
Core work and core teams have to be separated from non-core ones for optimization purposes at all levels. There would be two category of teams – one that interacts directly with customer and server customer, another that serves the teams directly serving the customer.
Once this is achieved, then focus on differentiating between different levels of teams. Different levels will require different performance parameters and optimization procedures. Think of training, tools etc for them.
There is a strong relationship between backlog and estimations oblique planning. In software project management during development phase development team is deeply engrossed in development of product in question. There has to be somebody who needs to minutely analyze backlog at short regular intervals so as to organize development in a very structured manner.
Mostly it is development manager who has to play this role. Every morning for example, development manager need to look at the backlog in the current development basket so as to ascertain actual team size and proper work allocation.
Team size is not a constant. It may vary during development phase depending on additional workload thereby demanding increase in team size or resizing of workload so as to decrease team size keeping in mind the time schedule remains same. In some cases if the workload during re-estimation stage if found lesser in size than the earlier estimations, may ask for two revisions.
One could be resizing of team size that means allocating some of the spared team members to some other project on ad-hoc or permanent basis. In this case the target time remains same. Another case could be where the team size is not reduced and time schedule is preponed.
Regular backlog monitoring helps a lot in estimating accurately thereby demanding a right size of team or giving correct target dates for covering backlog. While analysis of backlog and its scheduling, it is quite important to prioritize tasks as sub-components of backlog in a smart manner.
Segregation of parallel and sequential tasks of the backlog chunk is very important in task allocation to team members,
2. Product backlog needs regular analysis, planning, and re-planning.
3. Product backlog cannot be allocated to development team as a whole.
4. Product backlog subcomponent cannot be given to any of the team members.
5. Prioritizing and re-prioritizing of product backlog components is as important as breaking of product backlog into smaller components and sub-components.
6. Product backlog management works better if done by an expert who knows about product, team members’ capabilities and correct backlog derivation.
7. Product backlog tasks and sub-tasks need to be arranged in parallel possible and sequentially possible ones.
8. Team size and target timeframe are inversely proportional whereas product backlog is directly proportional to both.
9. Development manager is most appropriate person to manage product backlog.
10. A steep inclination or declination in product backlog means an emergency alarm and requires an immediate top management intervention.
Cricket and software project management has no link. Neither has John Wright, the New Zealand cricket team coach. But there are certain things happening around in international cricket that can help as learning for project management. In ongoing series between Pakistan and New Zealand, New Zealand could not play like an international team when their batsmen shattered like a sand dune in second innings. Whole team was out at just 110 runs thereby getting defeated by Pakistan by ten wickets.
Two things have happened after that as far as John Wright and New Zealand team is concerned. John Wright has very clearly and sternly told top order batsmen to tighten their belt and perform their job well without any excuses or explanations. If a specialist batsman is in team, his prime goal is to bat and not lose his wicket cheaply. That is what a clear cut message by the team coach to his team.
Second important step taken by John Wright is to drop opener specialist batsman Tim McIntosh from team and include allrounder John Franklin in his place. It is interesting to note that John Franklin has not played an international test match during last two years or so. But it seems to be a well calculated risk by the Coach for two reasons.
One reason is Tim McIntosh has not been able to touch double digit score in six of his last eight matches played. Another is by taking all rounder John Franklin there will be an additional bowler available in the team in addition to the regular bowlers thereby strengthening the bowling department.
Learning from John Wright, a project manager, under crucial situations has to raise an alert and alarm for his various teams lacking in delivery. Another important lesson is that there is no harm in taking calculated risks provided an in-depth research has been done for its pros and cons and be prepared for it in advance.
Let us take a case of project manager X who is well recognized in his organization for his capability of doing task well and before time, delivering project in time and up to the complete satisfaction of his management and customer, delivering in a quality way. It has happened due to some very good achievements by him as project manager that made his management proud of his capabilities.
Consistency is a big issue with this project manager. He is not able to finish his task well and before time ALWAYS. He can not deliver project in time and up to the complete satisfaction of his management and customer ALWAYS. He does not deliver in a quality way ALWAYS. If he has some very good achievements in his credit, there are more number of failures that overweigh his debit side.
He has some extraordinary qualities that nobody else has in organization but that does not qualify him to take charge of crucial projects due to his inconsistent delivery. Rather management would prefer to handover crucial projects to some other project manager posing less risk and threats for its failure or delays.
Even if management decides at times to hand him over some very crucial project, it is with a very high risk at the back of their mind and a careful attention towards Mr. X throughout the game.
A steep graph on both sides of his performance makes it quite a risky affair for management to decide giving him projects with a hundred percent assurance of success.
What will be your call in deciding as management executive for such project manager?
Bugs are a gentle reminder to respective developer and a sort of alarm for him to check nothing has been skipped as per user and business perspective. Bugs also act as useful and productive communication initiators between tester and developer till the individual loop gets closed either by execution or rejection of a bug. Bugs should be just on surface as close to the product developer as possible. That way it would be quite sensible and meaningful.
A tester must check the purpose of bug reported before submitting it in his/ her list of bugs. A bug is meant to highlight non easing spots in the software built where end user may feel uncomfortable to work. These spots need to be relooked into by developer so as to improvise on it.
An unnecessary or non purposeful bug may act as nothing but an unwanted noise in the sweet tunes of product built. It not only wastes time of tester but of all associated within bug lifecycle chain. These sort of noisy bugs reported may also act as distance creators between tester and developer which will be of no use to anyone in the teams.
Tester must be very cautious while report a bug which itself loses its sanctity being distant from the primary goal or purpose of a product or software.
A tester before adding or reporting a bug in his/ her list of bugs must be very clear about the gravity of problem being reported. As far as possible he/ she must add only those bugs which he/ she is very much clear about. Preferably while reporting a bug, a tester with his/ her knowledge of product being tested must propose a possible solution to development team which should be clear and crisp in nature. If development team finds it useful, there is no point they will not be in agreement to tester(s).
A bug reported goes meaningless most of the time if it is not clearly stated with an indication of benefits from its fixing.
Business value is not easy to ascertain, sustain, manage, monitor and improvise upon on a regular basis. But it is very important to do so. Somewhere sometime during my career one of my seniors advised me a very harsh truth of life. It was – “you cannot sit on your laurels”. What he meant was that everyday is a new day with no credit and debit from previous day.
The past successes cannot be celebrated for in present in lieu of current day’s laurels getting missed. Everyday is a new journey and hence new achievements need to be established on each day.
The same applies to business value too. Past peaks cannot be accumulated in current business value. Whatever has been achieved in the past has been delivered to the customer and hence cannot be treated as a new delivery today. Something new, fresh and better is required to achieve further enhancements in already established business value.
No accumulations are permissible. A classic example would be customer support. Your customer’s loyalty towards you is in lieu of consistent support given to them.
A regular good support given and customer loyalty gained in lieu of that will certainly abrupt the moment there is a downfall in support delivery or quality of service given to customer. Similarly you cannot expect loyalty from a customer who is not so well supported and in a way feels ignored from you.
Business value is a two way process.
Business value is never a constant. It changes with time. Its parameters also may change from time to time. A factor which could be inconsiderable a certain point of time may emerge as a considerable factor to be included at a later stage. So that means the number of factors and particular factors may vary from time to time to evaluate and assess business value.
A benchmark for business value always helps to spearhead and aspire for best. Business value evaluators and committee decisive about factors must have a plenty of knowledge of business otherwise the effort may go haywire.
For example good software is launched in a company which is not able to use it as they value more to the legacy software in use. The product launched may have a great value in market and in other businesses but here in this particular case in this company the product has no value though it has been bought and paid for.
If users and management here do not care for the product or use it, it cannot be treated as a good launch or productive sales if both the sides are taken into consideration.
Some factors may have more weightage than others in many cases.
There has been a long debate for many decades regarding quantification of business value. Is it possible to really quantify business value? Perhaps the answer would be no from most of us. Reason being it is actually not possible to quantify hundred percent. And probably the efforts involved in quantifying it would exceed the benefit without reaching to a purposeful state.
Even a whole heartedly effort is sincerely put into quantification of business value, it will never be possible to quantify it completely. If it is done based on certain assumptions, then obviously assumptions will play a major role in the results.
Though there will be some direct and indirect consequences and factors that could be directly and completely quantifiable. One example could be a high selling software that meets business requirement of most of customers would lead to high revenues and returns since there will be high demand for it.
Moreover if the same software is so highly bug free that it does not let users raise any doubt and problems then its market demand will rise further due to its good reputation. This can be treated as a quantifiable factor like revenues and sales. Moreover another factor of number of complaints reported by its users over a long period would be negligible and hence is quantifiable.
Satisfaction level in such a case would be very high among its users if a survey is conducted. Such a survey with realistic data can help in further boosting its sales among new customers.
We usually don’t evaluate a change request or requirement in accounting terms for both its purposes – expense cost and benefits value. Maturity of change management process depends solely on the organization that incorporates any change management process and its periodic evaluation.
The process adopted at one moment of time may not be as effective and useful the next moment. That is why a regular inspection and objective evaluation of any process makes sense to understand the maturity level of the organization.
Enhancement in any process at regular intervals also states the speed with which any organization would be maturing.
One way to look at a change or new requirement is the estimation of cost involved to incorporate it. There is another way to look at the benefit an organization gets after incorporation of that change or new requirement built as an add on to the existing application. Benefits could be in terms of time, manpower, accuracy, satisfaction of employee and customer; and so on.
A famous quote by Norman R. Augustine goes like this – “Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the second law of thermodynamics; i.e. it always increases.”
This one or two liner quote says a lot about the practical world of software development. And the story remains same globally more or less with a small variation. It is true that whatsoever approval processes you adopt at customer location during requirement analysis phase, some of the requirements always remain undocumented and unapproved.
Even with the involvement of all concerned in a business process, something or the other remains untouched, unnoticed, unrecorded, unmentioned and missed that comes into limelight only at a later stage such as implementation of software.
Better way would be to keep studying business throughout the development phase of software. This way could give you two way benefit – one, keeping customer’s key users engaged all through the journey; and second, getting each small phase of development vetted by customer management and key users on a regular basis.
This helps in avoiding any last stage volcano bursts and explosions.
Let us start with a famous quote by Dave Barry who said – “Software is usually accompanied by documentation in the form of big fat scary manuals that nobody ever reads. In fact, for the past five years most of the manuals shipped with software products have actually been copies of Stephen King’s The Stand with new covers pasted on.”
What does it imply?
Does it mean that software built and deployed does not require any manuals like fatty documents?
Does it mean that the manual instead of being a fatty boring document that is hated to be touched or referred to should be crisp and crux in a way that is really serves the purpose of a handy tool in case of trouble?
Does it mean that hard documentation era is gone now and users prefer to refer to on-line manuals or help contents?
Does it mean that the software built should be so powerful and strong that it does not really require a support document on how to drive it?
Are these manuals prepared really done seriously or just for the sake of formality only?
Does your manual invite suggestions, feedback, or shortfalls to be notified by your users? Do you take a serious note of such engagement of end users?
There need to be standard policy to manage a new project. Policy definition becomes prime important right in the beginning of a project that needs to be approved by management to proceed ahead in further project related activities. Once it gets properly defined and approved, its implementation is the next step. Only implementation does not fetch desired results in most of the organizations unless those are specifically very well synchronized with each and every employee self driven in right direction.
In all organizations other than those ideal ones defined above, after policy implementation, its enforcement becomes next important task for the organization. For that probably an awareness program could be held up in a physical or virtual environment to bring every one into sync.
Once it is implemented, enforced and deployed in an effective manner, its maintenance or sustenance should be the next goal of organization.
If you are successful in all the steps only then the mission can be treated as successful. Hundred percent successes of some steps and similar failure of other steps involved in total deployment of any policy may sum up as an overall failure of any policy.
A policy once defined and approved need to be launched in a proper manner so as to target all relevant team members and should equally involve some key top management persons strategically to make its deployment a grand success.
Change management takes care of any change in the organization that may or may not be directly connected to project. Change management and improvement initiatives may overlap most of the times. Reason could be the goals being taken to be achieved in any improvement process that seek some change in the organization.
Benchmarking, training, formal discussion forums, brainstorming sessions, workshops are some of the result oriented steps taken in an organization for the purpose of alignment or different brains present in the organization. Some of these platforms are best to address some common concerns.
Some of these platforms should also invite suggestions, complaints nad feedback. If these are not taken in negative sense and after well understood, these can be treated as most effective change agents.
There is nothing called shortcut for success. Change agents or improvement initiatives can not change the world drastically or produce significant results in a short span of time. Many a times improvement initiatives fail in organizations for such reasons.
Organizations initiate improvement processes for many purposes. Improvement process initiatives are like investment. Investments initiatives have various goals – short term goals, mid term goals, and long term goals. Same holds truth for improvement process initiatives too.
Organizations taking improvement initiatives are not always better than organizations that do not take any initiatives at all. Reason for this can be understood with two terms which are totally opposite to each other – acceleration and deceleration.
An organization taking an initiative but resulting in a failure achieves nothing similar to another organization that did not take any initiative. Sometimes initiatives taken are not bad but agents driving those initiatives may fail to focus on right targets of initiatives.
Change agents may be internal or external. A complete synchronization among all change agents is very important to get best results out of change initiatives. But overall whatever is the position of a change agent may be, it has to be effectively meaningful and purposeful for product users.
When a project plan is formulated in any organization, the purpose of exercise is much deeper than just defining a project plan on a piece of paper. A project plan can be further used to produce key performance indicators (KPIs) which in turn point towards the achievement of each goal defined in detailed plan. These KPIs can be taken up with two approaches – one can be top down approach where organizational KPIs are broken down further into each team’s KPIs which ultimately further get split up into each individual’s name.
Another approach can be bottoms up where it will be reverse of above. Each individual’s targets or goals become team’s goals. Each team’s goals further get compiled to form organizational goals. Similarly individual goals can be linked to individual’s KPIs. Team’s goals can be linked to team’s KPI. And organizational goals can be directly linked to organizational key performance indicators.
These key performance indicators are purely objective in nature which have to be measurable with the help of some pointers that define factors like success or failure against each one of them.
Each individual in an organization contributes towards its culture. Sometimes interests create conflicts among different members of a team in an organization.
Without bothering about organizational goals putting efforts in designing a framework for project management would be inappropriate for both streams. An individual is always different from a collective group in an organization. It is organization that rules over individual interests. That does not mean an individual has no entity in the organization but what it implies is that each individual’s collective and synchronized energy forms organization’s energy.
A good strategy can be formulated with help of in-depth analysis of market, competitors, customer’s geographic location, customer’s country political situation and so on. With help of all these factors a refined strategic plan can be designed for each project to take place for different customers customized for each one of them.
Without a proper plan no project can take place in any organization. Refinement of plan comes through two main factors which are organizational strategy and customer’s expectations. Planning is important for carrying out a project to give a commitment in advance before start of the project.