Various stakeholders of the project get directly or indirectly activities assigned to them so as to make the project run and finish. The major role in web application development is that of development team. They should be very clear about the customer requirements – what browsers they want to use, what browsers they desire, what version of the browsers, future expectations etc. If these web based requirements are not crystal clear, it is going to create troubles not only for the developers and testers but for customer also. You can’t just dream and design, you have to have specific requirements in hand to develop an application.

Similarly Testers role is also quite prominent in validating customer’s browsers related requirements and ascertaining that all the browsers mentioned by customer (essential and desired) have to be checked for running the application completely.

This small issue can create a major backlog at a later stage. So it has to be handled right in the beginning before the start of development.

1. Improved Process Cost: In past six months have you done any improvement in your existing process to make it more cost effective? If not, record it that there has been no improvement in this specific process past six months. It also proves that your Business Process Management is not effective.

2. Decrease in CoQ or Cost of Quality: If you are incurring the same cost on your process quality and there has been no reduction, it needs to be re-looked into the way it is being examined.

3. Improved PTT: Process throughput time should improve (decrease) gradually with the enhancement in the process.

4. Training Time: Don’t bother too much if your training time or training cost is going higher if you are meeting all other factors mentioned here 25% plus. If not, it would be a worry point.

5. Reduction in Internal Complaints: If process drivers and users have realized a substantial reduction in complaints pertaining to the process, you are definitely moving in right direction.

6. Reduction in Customer Complaints: The worst situation could be that customer has stopped complaining you about your product or system because you have stopped handling it. Jokes apart, if customer complaints have reduced and complaint resolution time has improved (reduced), it is a healthy sign.

7. Your ‘Surety’ about ‘Tomorrow’: If you are more confident ‘today’ about your ‘tomorrow’ than you were ‘yesterday’, you are steering your business process management well.

But mind it; this is an ongoing process itself. A small improvement and a big rest will make you worse than you were. You need to have continuous improvement.

When you start Business Process Management in any organization, your first task is to understand ‘where-is’ situation for all your processes. You will have to meet all business process owners – again and again to get more into it. The key factors of “Where-is” would be:

Process Cost: It is very important to estimate each process’ cost once you start this exercise. If you don’t know the cost of a process, you can’t manage that process, and you can’t understand what is lacking in that process and you can’t chalk out an improvement plan.

Cost of Quality: How much are you spending for the quality portion of a process? Is it visible and measurable? Or you might have to dig out further to arrive at this part. The cost incurred on finding/fixing bugs or errors is one of the major parameter.

Process Throughput Time: If you don’t measure it, start measuring it. If you don’t understand how to measure it, or what is it? There are ample ways to understand it.

Training Time: You might be incurring cost on trainings, have a record of all the trainings incurred ready.

Internal Complaints: Your process might comprise of say Hardware Support to internal customers within the organization. Analyze the data to assign various parameters that will help us in concluding certain facts at a later stage.

Customer Complaints (External): If the same process or system relates to external customers also, collect the data pertaining to customer complaints and resolution time.

Your ‘Surety’ about ‘Tomorrow’: If your processes are strong, your confidence will speak about it, if not, you will not be very much sure what is going to happen tomorrow. Check it – how confident are you?

And mind you, this is just the beginning. A lot more is yet to come…

In such a case the role of Project Manager can be sequentially summarized as below:
10. He has to understand well the total requirements of the customer
9. He has to map these requirements in the software already catering to other customers
8. This way he will be able to find out and check what is the impact of these requirements on the software?
7. He also has to check out if some practices already built in the software are better than what the customer is asking for?
6. He has to revert back to customer to discuss (and rather educate him) the benefits of adopting the practices already built in over the changes asked for
5. Customer might agree to some, and might still ask for the changes at certain places
4. Now the project manager has to sit with his product manager to convince him to incorporate these changes
3. Understand the impact of these changes and get back to customer if there is any adverse effect
2. Finally get those changes incorporated in the software
1. But don’t assume that the story is over…

How it needs to be managed, monitored and done is an art that requires certain level of high skills in the project manager who has to act as a solid bridge between the customer and the product manager. If we consider Project Manager, Customer and Product Manager as three different islands – it is the Project Manager who has to synchronize and gel well together all the three different islands in the journey of building or moulding the software to meet all the requirements of the customer. The project manager in this case is the center point with Customer and Product Manager on his two sides.

Internal requirements result from clarifications in customer’s existing requirements and enhancement of project team in business knowledge. Your team evolves better ways to manage customer’s existing and forthcoming requirements in a better way thereby seeking a change in existing code. It could be a major change asking for involvement of considerable number of developers for certain mandays. Or it could be a minor change involving just a couple of hours.

On the other hand, another scenario of change in requirements could be when your team of developers is working on building the customer requirements in the new or existing software and you receive a change note from customer requiring a major or minor change in the software.

10. Technology: Ensure that you are starting with the latest technology, as even the latest technology will be a little older by the time you complete the product.

9. Concept: Ensure that you do not start building a product that has several variants already in the market. Beat the drum to give the world a new beat.

8. Keep the air in your bag: Let the concept not leak out until you are ready to launch the product. Launch it with a bang. Advertise, blog, press conference, and whatever you feel appropriate for the launch. But ensure that your team confide in you in this exercise till you are ready to shout.

7. Convince, build trust: Convince yourself that you have chosen a right path even if it is risky. Demonstrate your management about your idea and the way you want to design/ launch it. Build trust among your team in giving a real shape to your dream.

6. Risk Management: It is very essential to jot down the risks involved, and ways to mitigate them depending on their severity.

5. Incentive: Let your team know what incentive they are going to get once the product and project is successful.

4. Project Sponsor: Mostly in such type of projects your management will sponsor the project, so all risk lies inside the house. Your stake is quite high in such projects. Equally important is the success of such projects.

3. Project Methodology: Adopt the right methodology and adhere to its requirements.

2. Project Plan: Ensure that such projects cannot tolerate much deviation in terms of time or money. Since in such projects all risk is yours, don’t let it increase at any cost.

1. Definition of successful project: Building a beautiful product in this case is of not any use if there is no buyer at the time of launch. Your total investment in the project can return only if you are able to find out a buyer.

Most common mistake that is made during the complete lifecycle of a project is not formally giving documentation (required at various stages) in project plan by assuming that documentation is not that prime. It is presumed that either the documentation will be done at the end or it is taken too casually and told to be done by everyone without assigning a proper ownership.

Both – Quality of Software and Quality of Documentation play a lead role in project management. Compromising with any of the two leads to increased cost, loss of customer satisfaction, delay in implementation or revenue loss.

What should be done in this sort of scenario?

The project manager privately updated me about the situation and asked for my help to get him out of this situation. I told him if he carries out in the way he is – he will never be able to finish his project.

I advised him to have an emergency meeting with his client and share his pain with them. Make them clear that you are not saying No to their requirements but there is a need of a boundary line drawn with mutual understanding. Cater to so far documented requirements as phase I. Finish it off. Get it signed off. Whatever new requirement or changes come from the customer – document it, analyze it. Any requirement that is asking for more than 4 hours of efforts, put it in phase II of the project. As soon as you finish off the phase I, finish off Phase II, sign off. And so on.