November, 2009

Project Management and the Risk Factor

Any software development and implementation project comprises of risks. The visible risks are easy to handle or manage. Invisible risks are more vulnerable. Invisible risks are like volcanoes that can erupt without any warning and can cause more harm. More harm because we never know how severe will be the intensity of the eruption.

The same happens in software also. Risks can come from any corner during the complete project lifecycle. Developers, testers, documents, process, methodology, customer, requirement – anyone or anything can generate a risk. During a project the project manager’s critical role is to be ready for a risk and manage it without hampering the project development. Like the variance in planning of tasks and their actual occurrence decides the timely or delayed completion of project. Higher the variance, more chances are for a project getting delayed.

A similar variance is the difference between perceived risks and actual risks. All perceived risks may not happen. All actual risks may not be perceived well in advance.

How your Web Application Performs on Various Browsers?

You are in software development and in today’s world you can’t escape from most of your customer demanding either replacing their legacy software in use with new web application or the development of a new web application. Every customer wants to keep maximum leverage for its employees in terms of mobility, flexibility, easy usability etc. and that is why most applications in demand are web based.

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.

Seven Key Factors for Business Process Management

Once you are in a situation where you understand your business processes (What-is), you need to know to manage them. Managing is not let-going, it is more than that. Managing is a regular process of understanding and improving. So let us discuss the major key factors that drive Business Process Management to make you understand if you are managing your business processes well or not:

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.

Enter the Dragon – Business Process Management

Are you ready for Business Process Management? As the title suggests, it is not an easy task or rather is an uphill task. You will find many roadblocks on the way to stop, deviate, misguide or befool you so that you are never able to reach your destination and wherever you reach – you will be convinced – as your destination. These roadblocks will be in the form of your peers, management, superiors, juniors and everyone else. Very few process owners will seriously cooperate you in this journey and the less you are aware about their business process, the more troublesome will be the journey for you.

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…

Ten Commandants for Project Manager in Requirements Change Management

Requirements Change management if managed haphazardly may become a disaster for both customer and the product, so it has to be managed very wisely and tactically. And the role of a project manager in this is very crucial.

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…

Project Manager – A Solid Bridge between Customer and Product Manager

Let us talk about existing software required to be implemented at a new geographical location. Definitely because of a different location there will be certain new requirements plus some changes here and there in the existing built to meet customer specifications. This need to be handled very minutely and tactfully in such a manner that on one hand it meets all customer requirements and on the other hand puts least burden on the team and software in terms of catering to those specifications or changes asked by the customer.

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.

How Requirements evolve during a Software Project?

New requirements or change in existing requirements is an inevitable process in any software project. As a project manager you encounter it during every phase of a project. Some requirements emerge internally by your own team and some come from the customer.

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.

Ten cautions in case of a self sponsored project

What if you have chosen to develop a product for which you don’t have a customer right now? If you perceive that by the time you complete development phase and the product will be ready to launch if will not be obsolete as per technology or concept, go ahead but take care of following cautions to be a winner in the game:

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.

Project Plans having no Place for ‘Documentation Process’ Compromise with the Quality

If we have to compromise with the quality of project at various stages there are many ways to do that. Most stupid way will be to compromise with the quality of the software which in any case is going to create lot of hue and cry in the organization either prior to it goes to customer during internal testing, or when it goes to customer for implementation. The undercover holes covered howsoever smartly will create seepage sooner or later.

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.