August, 2008

Aug 29 2008   10:30AM GMT

Project Management – V

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle

This is the last in my “Project Management” series. To enjoy this blog you will have to go through Project Management I  http://itknowledgeexchange.techtarget.co…), Project Management II  http://itknowledgeexchange.techtarget.co…), Project Management III  http://itknowledgeexchange.techtarget.co…) and Project Management IV  http://itknowledgeexchange.techtarget.co…).

Nothing is constant in this world except “CHANGE”. One this was clear by now that we have to change – immediately and without any further delay. To enhance our Project Management Process, we had already identified our weak areas, we knew what is to be addressed, and when it had to be done also was very clear – it had to be NOW. How? We had to think and analyze ourselves.

We had to transform ourselves in following respect:
Project Requirements: Not only the customer and business requirements but all project requirements need to be specific, clear cut, vetted by customer, documented – including any communication taking place thereafter – in form of email, telephone or otherwise.
Quality: Involvement: Testing team right from the beginning of the project and make them a part of development team, let them participate in all development discussions. Let them be very clear to identify the risks involved if the product is developed as per the project specifications and design finalized. Testing team has to be an integral part of the project now onwards, testing not at the final stage, but at each and every stage of development, by clearly identifying the scope of testing (unit, module, product, functional etc.) and highlighting the defect or bug at the moment it is encountered without waiting for submission of a test report (which in any case will happen but not after each defect identification!).
Sizing and Right Candidature: Go for the right size and right people while building a team for a project.
Backlog: Be clear about the requirements still pending to be catered to, built into the product. Count it as backlog, cut backlog into smaller pieces, and assign each element of backlog to a team member with the time plan (hours or max day).
Monitor: Regular monitoring of this backlog planned versus the completed is required atleast once a day. Involve only the concerned in the backlog as with the backlog resizing, the team also have been divided into smaller parts.
Involve Customer: Keep customer updated on each and every backlog completed. Let the customer, if they wish, to run through the backlog completed. Let the customer, if they wish, to check the balance backlog.
Release the Product: Release the product as per your commitment date. Any pending jobs (if at all!) may become the part of next release after their completion.

Hope you enjoyed the series.

Aug 28 2008   10:30AM GMT

Project Management – IV

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle

In my earlier blogs on Project Management – Project Management – I  http://itknowledgeexchange.techtarget.co…), Project Management – II  http://itknowledgeexchange.techtarget.co…) and Project Management – III  http://itknowledgeexchange.techtarget.co…), I tried to spot on certain defects in our project management process. All these defects or shortcomings were initially not visible due to small teams, small size of projects and different management perspective. But a requirement to relook into ‘project management’ arose when management had to change their perspective due to change in customer perspective.

This asked for introspection, analysis and thought process in which we identified certain factors as stated on my earlier blog “Project Management – III”.

All these factors were causing:
Missed Schedule – Most of the projects were either getting overdelayed by dying to their natural death prior to completion or implementation.
Missed Functionality – Lack of customer requirements, lack of documentation, isolation were few of the factors that caused the build of an improper functionality or totally missing it from the product. The customer living on another island was in a different imagination world dreaming about a different functionality and product as compared to the one being built (or missed) by the development team.
Missed Budget: Obviously – any delay in schedule, or building of a functionality that was skipped during initial built will ask for a fresh expenditure. Is customer ready to pay this additional amount?
Brittle Product: The product is too fragile or brittle that it is loosely threaded in such a manner that it will lose its flow or functionality during actual usage.
Quality Aspect: The product that is seeking changes during the later stages is always prone to weak quality due to time and budget constraints and various other pressures from customer side.

One thing was clear by now that we need to change, as there is no alternative. We need to change to strive, to exist, and to deliver. We need to change to get out of our static system. We need to change to meet customer requirements. We need to TRANSFORM – OURSELVES, OUR PROCESSES, OUR THINKING.

Change – What and How – wait and hop on to my next blog in the series – “Project Management – V”

Aug 26 2008   10:40AM GMT

Project Management – III

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle

To carry on further from my earlier blogs on Project Management I  http://itknowledgeexchange.techtarget.co…)and Project Management II  http://itknowledgeexchange.techtarget.co…), this is the third in series. Project Management in my opinion, is not a static Management, it is a dynamic state. It keeps on giving a new learning in every project, and seeks changes in the project management process. There are instances where the earlier project management methodology of freezing customer requirement with a document preparation, a sign off from customer, stating that the document is sufficient to cater to our requirements and the software be built based on these requirements mentioned in the document. Now the requirements may change during development, or even implementation, during any stage of project management. You can not say ‘no’ to those requirements asking for change in software, as you know very well that ultimately a ‘good software’ is the one that caters to the customer requirements and customer business than to those mentioned in the ‘business study document’.

What we lacked in our methodology of project management mentioned in my earlier blog “Project Management – II” was – a clear cut ownership of the project, involvement of all concerned throughout the project life cycle. Documentation was another weak area – documentation of not only the requirements, but of system design, database design, communication (internal and external) associated with the project. And above all, the random and isolated involvement of different stakeholders, like QA will enter into the project only when the product is complete and ready for testing.

Now, of above, imagine the time spent on QA to make them understand the complete product right from scratch, that too in absence of complete documents.

Aug 22 2008   10:30AM GMT

Project Management – II

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle

As discussed in my earlier blog on project management (Project Management – I, http://itknowledgeexchange.techtarget.co…), different organizations adopt different procedures, processes and policies for their Project Management, and then keep improvising them until they reach at the level of ‘best’. Best practices in ‘Project Management’ are not a single set of practices that are used by various organizations – but rather I would say any ‘good’ practice when used to its best of effort, sincerity and energy becomes a best practice. Any best practice in Project Management asks for involvement, from all levels, starting from top management to the junior most level. Here, I would discuss some practices in software project management, which we adopted earlier, then brainstormed on those practices that where we were as compared to the best practices being adopted and followed by various other global organizations, analyzed where we need to change and how we need to change with clarity of visible benefits out of those changes adopted.

Initially it was a purely waterfall scenario – with the sequence as – Requirements and System Analysis, System Design, Testing, Implementation and then support finally. This was going well for years, without any much of issues. But later when we grew and analyzed we found that it goes well with small team sizes, small projects, fixed requirements, in scenarios where reporting of apparent success to management was sufficient.

But we found a resistance in out own system – team sizes were not small now, projects were of all sizes – small, medium and large, requirements were never definitive and we have to be open for any requirement change asked by customer during a project, and above all management is not at all interested in any offline report showing progress of the project – rather they are interested in ‘progress’ if it goes well without any ‘reporting’. That means the management wanted to see the progress – visible and in unanimity with the customer (internal as quality, and external as the Product Owner).

Aug 20 2008   10:21AM GMT

Project Management – I

Posted by: Jaideep
Project Management, software engineering, SDLC, Project Lifecycle

Project Management is nothing but adoption of a set of processes to ensure the smooth running of a project development passing through various stages and its successful and timely completion. It is the crux of any project as I too believe that it is not the people who make the projects successful, it is the processes and procedures adopted by the management responsible for the project. Project Management depends on how matured a company’s processes and procedures are. Broadly in terms of Project Management, organizations can be divided into three categories: First category will be of organizations having no or a very little system in place for Project Management. The organizations falling in second category would be those who have processes and procedures in place but not adequate for 100% successful Project Management and hence those organizations keep on striving for improvements by continuously analyzing, trying, good practices for enhancements, optimization, and successful project management. The third category of organization would be those who are matured, balanced, and a showcase for other organizations. When I say balanced, I mean they are neither too rigid nor too flexible in their practices. These organizations have a set of best practices in their sleeves being used for years, time and tested again and again. They would decide upon the best suitable practices depending on a specific project. When I say matured, I mean their success rate is higher than their peer organizations, they are the best in Project Management. Their employee turnover ratio is quite less, their employee satisfaction level, energy level and passion level is higher. They have not only adopted the best practices in their system, but in their organization culture, and in the blood of each employee.

For first and second category of organizations, the journey is long to reach to the final level, but equally higher is the scope to achieve it. Provided they have an urge, zeal and fire to achieve it, they stay on their levels for years. It is the management that has to drive it and for management it is sooner the better looking at the competition at global level and the expectations level of the customer. That does not mean that for the third category of organizations it is the end of the journey, rather it is difficult to maintain, sustain and keep improvising as everyone knows it is easier to reach at the top once than reaching every time, and maintaining it.

Aug 18 2008   10:18AM GMT

Project Management – A Sad Story – II

Posted by: Jaideep
software testing, Project Management, Development, software quality, Quality Assurance, software engineering, SDLC, software qa, Project Lifecycle, software testing cycle

This is in continuation to my earlier blog “Project Management – A Sad Story”  http://itknowledgeexchange.techtarget.co…). Keeping all the character names same as described there, I will update my readers on what happened to this particular project headed by Roberts. Although Roberts is new to these projects but is trying his best to get into each issue and address it appropriately keeping ‘common sense’ part intact while making a decision. Roberts knows and often tells others that project management is not only about the management of a project, it is about managing people working under you, it is also about customer. The story takes a couple of twists and turns and moves altogether differently.

Julia, the project leader, accepts her defeat, and resigns from the organization. Linda, Lisa, Paula, Edger and Alex are doubtful about the success or completion of this project. The issues that arose at customer site were majorly two as stated by the customer – one is that Julia is not competitive enough to understand business requirements and embed them into the software, and second is that Team has no purpose in staying at customer site till the product is complete. So they sent the team back to their country. Julia’s resignation is accepted as management also feels she is one of the reasons of this failure. Sandy, the QA head, is given an additional charge as project leader of this project. Sandy has a good record or project management and has been 100% successful in all the project he handled so fat prior to becoming the QA Head. One would wonder when he was so successful in Projects, why he became QA Head. Probably he knew that this Quality of ‘quality; of a product in him is one of the key factor for all his project management success. Sandy accepts this challenge but with an apprehension that before Julia stops coming to the organization, she atleast explains him the complete picture at customer site about project, requirements, and customer. Sandy has to not only take care of all customer needs to be built in the product, but also to ensure the quality aspect of it. The project is delayed by 20 odd days. Development team is working in the customer requirements. Sandy is overall now is the linking part between offshore customer and his development team (and also for his testing team).

Only apprehension Sandy has now is that if the fresh requirements brought by Julia were complete and exact or still if he has to face the similar situation again!

Let us wait and watch!

By the way – what is your opinion on this – what would happen to this project – SUCCESS or FAILURE!

Aug 14 2008   10:35AM GMT

Twelve essential Steps of Software Testing Life Cycle (STLC)

Posted by: Jaideep
software quality assurance, software testing, Project Management, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, Project Lifecycle, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting, STLC

STLC (Software Testing Life Cycle) is an integral component of SDLC (Software Development Life Cycle). Gone are the times when any software was made on the basis of its requirements and the moment it used to get completed by the development team, it got released to the customer. But now, Testing has become a distinct phenomenon during and after the development of software. No software is released to the customer without a comprehensive testing by QC or Testing team in the organization. The Scope and Methodology may vary from product to product, customer to customer, and organization to organization. There are certain aspects of Software Testing Life Cycle. To name top few among them, I would like to list twelve essential steps of Software Testing Life Cycle.

The Steps are to be followed from the start of Testing of software to the end of the testing as follows:
1- Before the dynamic testing, there is a static testing. Static testing includes review of documents required for the software development. This includes following activities:

(a) All the documents related to customer requirements and business rules that are required
for software design and development should be handed over to QA. These documents
should be complete and dually signed by client and representative of the company
(usually Project Manager).

(b) QA reviews these documents. The reviewing of documents includes comprehensive and
thorough study of the documents. If any discrepancy is found then it should be noted
and raised in the review meeting with the Development team.

(c) After this there should be a formal meeting between the QA and development team
regarding these documents, the agenda of this meeting mainly includes what is missing in
the document, QA queries to be answered by Development/Project Team and/or
clarification required for any confusions.

2- After the Software development or build of a module, QA starts dynamic testing. If during the development the requirement has been changed on customer demand or due to any other reason, then that should be documented and a copy of this revised document is given to the QA and also discussed as explained in point 1 above.

3- Development and Testing environment should be made clear to the QA by the Development team. It include the following activities:
(a)- Server to hit for Testing
(b)- Installation of latest build on the test server.
(c)- Modules/Screens to test.
(d)- Test duration as decided by test manager and project manager mutually based on scope
of work and team strength.
(e)– Demo of the software on test server by development team to the QC members.

4- After this Test cases and test scenarios are prepared and then the Test execution by QC.

5- A comprehensive Report of Bugs is prepared by the Testers and a review/verification by QC/QA/Testing Head takes place. Before handing over this report to Development Team there is a thorough review of Bugs List by Test Manager and in case of any clarification required on a bug submitted, the Testing Head discusses the bugs with the assigned tester.

6- Release of bug report by QC Team to Development Team.

7- Discussion/simulation of bugs by QC with development team if development team requires and time required for fixing the bugs should be made clear by Dev team at this stage.

8- Feedback from Development team on reported bugs with the stipulated time frame required to fix all bugs.

9- Any changes in the software being made in respect to fix these bugs should be made clear to the QA team by the Development team.

10- Testing team then Retests or verifies the bugs fixed by the development team.

11- Submitting the retesting bug report to the Test manager and after this the step 5 to step 10 are followed until the product has reached a stage where it can be released to customer.

12- Criteria for ending the testing should be defined by management or Test Manager Like when all major bugs are reported and fixed. Major bugs mean the bugs that affect the Business of the Client.

Aug 12 2008   11:00AM GMT

Eight Checkpoints for Testers during Software Testing

Posted by: Jaideep
software quality assurance, software testing, Project Management, Development, software quality, Quality Assurance, software engineering, Software testers, SDLC, software qa, software testing cycle, Software testing methodologies, software testing procedure, software testing process, software testing projects, software testing strategy, software testing tips, softwaretesting

Testing is a process of facilitating development team/ project team in improving the quality of software before it is released to the customer for use. Some key essential steps are always there that need to be followed by the Testers during Software Testing to streamline the process. The most important checkpoints for testers during software testing, in my opinion, would be:

(1)- Complete document of customer and business requirements specifying all the requirements for the development of the product.

(2)- Latest completed build and URL of the application to hit for Testing.

(3)- Software requirements for installing the application on PCs for testing or for database connectivity.

(4)-Training/Demo of the project by development team to Testing Team so as to understand the flow/functionality of the software.

(5)- Scope of testing should be made clear by the development team/Head.

(6)- If the build comes for retesting, then it should be accompanied by the revised document which includes the updated changes incorporated in the software.

(7)- Clarity regarding which member of development team should be contacted in case of any clarification required during the testing phase regarding the functionality of the module or if testers encounter a showstopper in the Software.

(8)- After release of the bugs list to development team, how much time they will require for fixing the bugs.

Aug 11 2008   10:25AM GMT

Offshore Projects

Posted by: Jaideep
Project Management, SDLC, Project Lifecycle

On his blog by the famous Leader on Project Management Bas de Baar, he asked a question to all his blog readers – “What is the best advice you can give to project managers supervising offshore development projects?” Various readers posted their opinion as per their perception, experience and learning. His focus was more on Offshore development projects, whereas I would like to point to any offshore project that has to be developed implemented on site. So in context to offshore development and implementation of a project, a project manager has to essentially develop some soft skills other than his/her standard project management tools and methodologies. According to me for an offshore project management following would be the essential key requirements as I am sure every one of you will agree that an offshore project is definitely different to an onshore project. The basic things to be taken care of in context of that country, management, users shall be:
Language: Understand what their prime language is in day-to-day use. I went to a country where language was a big barrier and I was heading the project. Before going there, I learned few of the commonly used words, downloaded a dictionary to translate from English to their language. Although very few of my users were fluent in English, and I used them extensively as a medium to translate what I used to say in my training sessions. But there were instances when I am sitting with a couple of users who don’t know English or who know very little of English, then this offline/online dictionary was very helpful. Also I learned before hand that they speak English very slowly and can understand only if spoken in low speed and a different accent (like “show” will be pronounced as “cho”). Ascent was another criterion that I had to gradually master upon. This will also depend on deciding upon the pace of the project. I had to change my plan accordingly to cover up the backlog at times.
Culture: They will love if you talk about their country and culture, and that is the best way to make them your best friends. Then it was easier to understand them faster. Learn about their likings and disliking, what they don’t like is very important, or what annoys them easily, so avoid doing that or using those words. Don’t refuse to attend any of their customs when invited. After all it is the people that make any project success. And most of the people outside will be interesting to know your language or culture, do not hesitate in sharing your knowledge/skills and spending some time on this, although it is not the part of your project but it will develop into a very strong tool to progress your project in right direction with right pace.
Be as them: Don’t act as a foreigner. Act as one of them. Show the management that you are the part of their organization and it is not only their but your project also. Keep top management involved in all your decisions and actions. Seek their help where required.
Celebrate: Celebrate any small success that will motivate them and speed up the implementation.

Do let me know anything that I might have missed to mention.

Aug 3 2008   9:10AM GMT

Project Management – A Sad Story

Posted by: Jaideep
Project Management, Development, Quality Assurance, Software testers, SDLC, Project Lifecycle

Cast:
Roberts: Project Manager
Laura: Project Manager
Julia: Project Leader
Sandy: Quality Head
Toby, Andy, and Victor: Software Testers
Linda, Lisa, Paula, Edger and Alex: Module Leaders

Storyline: Project Manager, Roberts has newly been shifted to manage various projects (running or in pipeline) as this post got vacant after the resignation of Laura. Roberts prior to this was head commercials and this is a new avenue for him, he now handles many projects at a time and is okay with it. Julia his Project Lead for the project in question is leading a project for the first time. She has been involved in project implementation earlier but as a module leader and not the project leader. Sandy is the Quality Head and is responsible for the QC of any software that goes to any customer. Toby, Andy and Victor are reporting to Sandy. Linda, Lisa, Paula, Eder and Alex are working on different modules of the project lead by Julia.

Laura was a cherished leader a year back, as she was able to grab quite a good number of overseas projects. But somehow she failed to manage the projects as each project got overscheduled due to one reason or the other. Ultimately, Laura had to admit her defeat, and she resigned from the company. But does it solve the problem? No, the company by now is in deep troubled waters and has a big question mark on its reputation for the existing and future projects. Julia and the team were already designated by Laura and were sent to the client site for implementation. Sandy and Laura were not in good terms as Laura always wanted Sandy to bypass the defects in the product and wanted him to give a go-ahead for implementation without worrying about the completion of the product (or ignoring unfixed severe bugs reported by Sandy’s team).

Roberts did not disturb or made any changes in this particular project team lead by Julia. Julia and team are back from customer site without completion of the project as some issues arose which could not be handled by Julia. Few of the outcomes of the team and team leader that are back from the project (still incomplete) are:
1. Toby, Andy and Victor were not happy with the state of the software when it was taken for the implementation at customer site
2. Sandy had clearly told management in advance that there are chances of project failure
3. Linda, Lisa, Paula, Edger and Alex are not happy with their leader Julia as they feel that Julia who is also heading a module of this project is always over occupied in her module and has no time to address project or other module issues
4. Julia was not able to convince customer management about the product
5. Many business rules that were built in the product shockingly absolved as the wrong requirements understood by business study team.
6. Julia is not happy with her team members – Linda, Lisa, Paula, Edger and Alex as she feels they are not listening to her and doing whatever they want to do without consulting her
7. Julia and her team were all sailing their individual boats in different directions at customer site.
8. Julia feels she is the team lead just on papers otherwise it is being lead by someone else.
9. Roberts feels that the initial system study done at the time of Laura was not satisfactory and accurate.
10. Roberts also feels that even now when the team goes back for implementation of the same project, there will certainly be many issues.
11. Roberts is not sure about the timeline or schedule of the project, that whether this time the team lead by Julia will be able to finish the project in scheduled timeframe, but is not worried as he knows that the management will accept his failure because he is not the one who started it. He feels secured even if this project fails as he is sure that the management will not him fully responsible for this, or even if it happens he can pass on all the blame to Laura who is not with the organization now.

Ultimately how do we ensure the successful completion of this project in stipulated time is a big question (although it is not disturbing anyone as everyone has already a bundle of reasons in his pocket)?

Does someone have the answer?