software

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.

Project Scope – Customer needs to be shown the right path

One of the project managers of an ERP implementation company got himself into a tight corner. He found himself in a tough situation where an already ‘mutually sealed’ project scope asked for one or two new requirements (or changes in the existing functionality) from the client everyday while implementation. The broadly agreed upon requirements within the earmarked project modules came out with some changes here and there, some new add-ons. Customer is not ready to accept ‘no’ to any of the requirement since they have a mindset that they have ordered for a big project and are investing a large amount of money in it. The customer keeps on pushing for all their ‘now invented’ requirements to be mapped in the existing ‘project scope’. This seems to be a never ending story. The project manager is tightlipped to start a new module since the running one is not ‘done’ so far. And he also can’t say NO and mark any requirement as ‘out of scope’ since he does not want to annoy the customer and wants the project to be a success.

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.

Five ‘must-have’ skills to be a Business Analyst

As stated in my previous post, a Business Analyst is a quite powerful role that establishes the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer. Let us see what are the ‘must-have’ skills without which a business analyst can not survive? And why are those skills so important to be a business analyst? Without any relevance to the order in which they are mentioned (as all are equally important) these skills are:

5. Business Knowledge: A good amount of experience/ exposure/ knowledge of customer business are very important for a business analyst

4. Listen and Understand: A business analyst has to be a good listener and with a sharp understanding power without which all the discussions with customer will be fruitless.

3. Technical Knowledge: There will be quite a few technical discussions at customer site. The BA has to be quite conversant with the technologies and methodologies present at his organization.

2. Communication: A business analyst has to be a strong communicator. During the customer meetings, if he does not communicate well about his organization’s capabilities to build up the trust and confidence, probably customer may not gel well with his ideas.

1. Writing skills: Very important skill required for documentation and for conveying the right messages across the board.

Various roles of a Business Analyst

Business Analyst is a quite powerful role forming the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer.

For a software company having various new development projects a business analyst has to understand the existing business processes, methodology, rules etc. of the customer, document it (which itself is a specialized task) and hand it over to development team to embed the customer requirements into the software to be built.

For a software (or IT) sales company a business analyst has to sit behind the sales/ business development teams – understanding their current process of acquiring new business or sustaining current business and bring out a better approach, methodology, process to enhance business in terms of new business and holding current business.

For a manufacturing company a business analyst has to understand the process, re-engineer it to enhance the production, product yield, thereby increasing customer satisfaction and reducing defects or rejections.

A business analyst ‘s various caps thus include – business process analyst, business strategy analyst, business methodology analyst thereby becoming a backbone to business process managers, sales teams, management, development teams , product teams, quality teams etc.

Five Tips for a project manager for driving (and completing) a Project successfully

Involve all stakeholders throughout: This does not mean that all people involved in the project have to keep them available full-time during the project but it means that the knowledge about the project, project progress, shortcomings, bottlenecks etc. should be continuously shared across the board universally. All members should have the same set of information available with them at any moment of time. Involvement will definitely vary from person to person and phase to phase.

Collaborative, Participative, and Interactive: The information flow should not be one way. It should comprise of praises, shouts, appreciations, arguments etc. Let each brain contribute in making it a success.

Be Demonstrative: Lead the project. Demonstrate by actions what you want from other members. Use fewer words and more actions, especially in case of crisis or a problem.

Identify the lazy goat: If there is any lazy goat that is bound to spoil the show, indentify it at an earlier stage so as to avoid higher risk at a later stage.

Keep a set of your customer shoes with you: Borrow a set of your customer shoes, and keep it with you during the project. Put off your shoes frequently, wear your customer shoes and then have a look at the project pace, progress and status. It will definitely give you a different perspective view.

20 gems for project managers

1. A project manager is always right
2. Quality is seriously maintained by developers while developing software
3. A separate set of people (quality control or testers) is not required to take care of the software produced or developed
4. Testers don’t do any substantial value addition in product development
5. Testers lack business knowledge
6. Testers lack technical knowledge
7. Testers lack essential skills to test software
8. Testers don’t understand product requirements well
9. All developments and implementations are prone to extensions because of change in customer requirements or other customer constraints
10. All delays in development and implementation are due to customer
11. Testers have a very little role to play in product development
12. Testers need less than 1% of project time for testing and reporting bugs
13. Testers should be able to test the product well even if substantial knowledge related to product has not been shared with them
14. Testers are the biggest misleading agents
15. Developers and programmers are not testers and thus are not supposed to test what they develop
16. Testers are de-motivators to programmers and developers
17. Testers are project delayers
18. Customers blame development and implementation teams just to hide their own shortcomings
19. Customers don’t know to explain their processes and business rules well
20. Customers are always interested in delaying the project

What customer type you are?

One customer type focuses on current requirement, rightly built, with more flexibility towards the business requirements built-in in the database rather than in the code. They believe that if the software meets their current requirements well, the future requirements will be built in at the need of the hour. The reason for this is that nobody at the moment is sure about the future requirements and when the change will be required. The change could be required one day after the current implementation or after five years. The changes required could be insignificant, small or not so much effort consuming.

Another type of customer is who is more worried about tomorrow without focusing more on the current built. The future requirements which are not too clear at the moment, are guessed by the customer and forced to be built in the product without really understanding if these requirements will ever be used, or if the requirements built are correct as per future needs as nobody can define them correctly at the moment.

Probably if requirement handling is managed more at database level than in the code, it gives more flexibility to the product.

Ten facts (or myths) about developers and testers

We all know developers and testers both have a tough job all the time. Developers have a key role in developing the software as per customer requirements embedding customer’s business needs into it. Similarly testers have to put all their efforts in ensuring that the software is matching customer specifications flawlessly and is bugs free. In a nutshell both developers and testers have a common goal of ensuring a superior product delivery at customer end. If that is so why there is a never-ending tussle between testers and developers. Why developers feel testers are unnecessarily trying to poke their nose into their affair. Why testers feel that out all the bugs found out by them, most of the bugs would have been already handled by developers if they had done their job more seriously.
All this leads to certain questions about testers and developers which they only can reply to:
1. Testers are not supreme and so are developers. If developers can build so many bugs while writing the code, testers are also bound to leave certain loopholes in their testing. This is universal and never ending story.
2. Most of the testers around the world who test software do not understand very well the purpose behind the testing. They keep oscillating between their role as policing, controlling quality and excessive reporting.
3. Both developers and testers carry a single goal of ensuring good quality of software at the end of the day but still keep blaming each other for the shortfalls.
4. If developers are kept for writing code, it is well understood that they are being paid for writing good code and not bad code. Then why bugs at all? If a developer has been hired for coding, is it wrong at organization level to expect a 100% bug free coding from developers. If they are permitted to write code with bugs, why not every other function in the organization is allowed to perform their daily tasks with errors. Can’t we have perfect coders?
5. If testers find out the bugs, instead of being thankful to them, why developers start finding out reasons of cornering them. Developers are hurt when testers find out bugs in their code, and instead of going into a thanks mode for testers they start going into another mode where they themselves start losing their respect. In turn they start finding out weaknesses in tester’s capabilities, testing criteria or bug reporting process.
6. It is a well proven fact that while fixing reported bugs developers are bound to generate new bugs. Does it not make them circling them around the same product?
7. Testers sometimes have an understanding that if they report less bugs will mean a question mark on their job, which forces them to report many a times non-quality bugs thereby increasing gap between developer and tester.
8. Developers, once they know that the product has to undergo testing, write code so foolishly that they generate lot of unexpected bugs.
9. If testers are hired for finding out bugs, is it not their lack of depth of knowledge that leads to bug explosions at the later stages? Are testers involved in coding, or business study or implementation?
10. If developer’s after reading so many books on development write codes with bugs, I don’t think a good tester criteria should be if he has read a book on testing or not.

The 80/20 rule in Software Testing

Pareto Principle or Pareto Rule is quite fascinating in managing personal and professional life, time management, task management, self motivation etc. Crux is if you focus few vital issues in life you manage major part of your life better. The same applies in profession, organization, department function, and activity too. Only thing is it is to be applied objectively, and smartly.

Let us see how it can work in terms of software testing and quality control:
80% of software quality is maintained by 20% of programmers
80% of bugs in an application are written by 20% of developers
80% of bugs are fixed in 20% of time
20% of a business application accounts for 80% of bugs

The 80-20 rule for Developers

The 80-20 Rule or most commonly known as “Pareto Principle” was first formulated by the famous Italian economist Vilfredo Pareto in 1895. The principle was named after him and still holds good almost in all the aspects of life. Vilfredo Pareto found that 80% of Italy’s wealth was with 20% of people. The crux of the principle is that most things in life are not distributed evenly. That may imply that in an organization 80% of decisions are taken by 20% of people. In a manufacturing unit 80% of production is done by 20% of workers. In an class of 100 students 80% of intellect lies with 20% of students. And so on…

In a software project management, based on 80/20 rule, it may be concluded that:
20% of code manages 80% of business in a business application
80% of developers write 20% of code in a team of developers responsible for writing a business application
20% of total productivity of a software developer produces 80% of results
20% of core business requirements, if focused and built well in an application, account for 80% of customer satisfaction
20% of bugs fixed make 80% of software bug-free

And so on…