Aug 21 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
software testing,
testing,
software project management,
outsourcing,
Project Development
On LinkedIn an IT projects guy posted a question about plus and minus of outsourcing software testing for his software project. After getting 12 replies from various experts he posted his intention behind this question. The intention was to outsource development and testing to two different vendors (‘slicing’ in his terms) so that they maintain a self-check on their performance and resultant.
My next post immediately after his last post regarding his intention was that if he had clarified this right in the beginning at the time of posting his question, he would have got better replies rather than experts posting their views on pros and cons on outsourcing ‘testing’ or not.
Well my last post said there the same. And I added – “if you are slicing – then make 10, 20 or more slices and distribute it among all your vendors. This will also call for more self-checks”
What is your take on this?
Jul 8 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
project manager,
project team,
project monitoring,
Project Plan,
Project Planning,
Project Development,
project implementation,
Software Project,
software development planning,
software product
At the birth (inception) of a new software project the project manager is puzzled and confused just trying to gather and understand customer requirements. He starts like a wanderer in the dark islands of customer for collecting various requirements and understanding their business norms. The moment he is able to collect this information, he aggregates to get the stock of ‘total requirements’. Understanding this makes him getting into ‘catching the rhythm’. Now comes his planning phase where he has large ‘in depth’ discussion with his development teams. By identifying different milestones for various project stages, he prepares a project plan. At this stage he is supposed to discuss this plan with customer and get ‘in sync’ with him. Once approved from customer, he breaks this plan into different stages plans to hand over respective plans to their ‘stage owners’. Development plan goes to development manager. Quality plan goes to QC head. Implementation plan goes to implementation head (himself mostly). Accordingly each stage milestones are identified which might be more than overall project milestones shared with the customer.
Then starts the actual war phase – the development phase. Meetings, discussions, brainstorming, logs, monitoring are all the weapons of this war phase. A product gets birth during this phase which gets vetted by quality control team. Documentations are also integral part of this phase.
Various test phases occur during and post development or build phase. Smoke testing, Unit testing, module testing, performance testing, security testing, load testing, functional testing… to name a few.
Now the baby has started walking. So baby is dressed well to take it to the grand function taking place at customer site. The function is ‘Implementation’. This is a long function, comprising of baby show, meetings, discussions, demonstrations, recordings, UAT, training etc. Once the baby is able to walk neatly in front of all the guests at the function, all praises fall on baby. The ceremony closing takes place. Project manager adds one more bullet of ‘confidence’ in his gun.
And starts over again for a new project.
May 11 2009 10:12AM GMT
Posted by: Jaideep
change management,
Software Project,
Project Management,
project cycle,
Project Development,
software development,
software implementation,
project implementation,
software requirements,
business requirements,
business study,
project manager,
Business Rules,
customer management,
customer requirements,
project team,
business critical change
Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.
At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.
At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.
Feb 27 2009 9:54AM GMT
Posted by: Jaideep
software quality,
project quality,
quality standards,
quality measures,
quality metrics,
software metrics,
Project Management,
Software Project,
customer requirements,
software product,
software design,
business requirements,
functional requirements,
software delivery,
Project Delivery,
project execution,
project initiation,
Project Development,
project implementation,
software strategy,
test strategy,
test case,
Test Plan,
test scenarios,
test results,
fixing of bugs,
project close-out,
post implementation phase of project
The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.
In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.
In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.
The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.
Feb 11 2009 11:04AM GMT
Posted by: Jaideep
Project Management,
project manager,
Software Project,
project task,
project milestone,
software team,
programmer,
developer,
technical,
coder,
coding,
programming,
Development,
Project Development,
project progress,
project completion,
PM
A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.
Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.
Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.
So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.
Milestones have more visibility as compared to tasks.
Feb 4 2009 9:54AM GMT
Posted by: Jaideep
Software Project,
project manager,
PM,
software development,
Project Plan,
Project Status,
Project Development
The most wrong statement from a Project Manager to the management during a project can be – “Everything is as per plan”. This is never, never possible during a project where a software development is required. If this is the statement from the Project Manager, there could be two realities behind it – one, either he is being cheated, or two, he is cheating the management (and in turn himself!, phew!). This could be due to (again two reasons) – either he is unaware of the facts, or he is trying to hide the facts. The first factor (being unaware of the facts) can be overcome with the help of some discipline and procedures, but if the second reason is surpassing the first one, then organization (both – the customer and vendor) are in trouble.
To overcome the first reason i.e. not to fall in the category of “not being aware of the facts”, the project manager has to follow certain guidelines, the prime could be:
1. Keep an updated project status report with you. (the frequency of updations could be in hours or days, but not in weeks or months).
2. The components of your project status report have to be –
Planned vs. Actual Tasks
Planned vs. Actual Efforts (mind it, there is a difference between the monitoring of tasks and efforts, and both play a major role in a project. Monitoring of both is essential)
Tasks completed
Tasks requiring no “re-do” or “re-look”
Tasks requiring a “re-do” or “re-look”
Efforts/ hours “over spent”
Open bugs, risks, issues
List of customer requirements pouring in after clarification from the customer (during development). (and don’t tell me that there are no clarifications required from the customer during the development phase)
The balance efforts, with time, resources allocation and concrete plan. (this has to be as crisp and realistic as possible)
Jan 12 2009 10:04AM GMT
Posted by: Jaideep
software quality assurance,
software testing,
documentation,
Project Management,
software,
Development,
software quality,
Quality Assurance,
SDLC,
business management,
software development,
Project Lifecycle,
software requirement,
business requirements,
Project Development,
customer requirements,
defect free software
In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.
4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.
3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.
2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.
1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.
Jan 7 2009 9:59AM GMT
Posted by: Jaideep
Project Management,
software development,
SoftwareProjectManager,
Project Head,
Project Development,
Development Manager,
Refrence Model
A reference model is a non-arbitrary model of software that is to be referred to when a new software requirement comes from a customer. The reference model will suit and fit most of the requirements given by the customer. The model is the most ideal scenario befitting the technical and functional requirements. Although the new architecture built may not (and will never) match point to point with the reference model but still it has to be as near to it as possible. Infact the reference model has to be capable to address all technical issues that may arise during the software development. During the development if a new problem is encountered, it becomes the part of reference model too. For development also the different components of the repository of the reference model are picked and absorbed wherever found suitable. So the various components are picked and fixed as it is in the software or are reworked with minor changes keeping requirements in mind.
This process not only shortens the development timeframe but also brings in more accuracy and stability in the product. It also helps the project manager to present the near to exact time and cost estimations. The reference model acts as a block of utilities or functions meant for the software being built. The best suitable blocks are selected and placed as it is. The most suitable blocks are selected and placed with a little modification. This increases the reusability as well. Reference model works as an outline sketch of the new product being developed.
Jan 2 2009 9:45AM GMT
Posted by: Jaideep
Project Management,
software,
software development,
developer,
tester,
project manager,
team management,
measuring effectiveness,
Project Development,
Development Manager,
timesheet,
tasksheet
In an organization engaged in software development business, timesheet is filled by all developers and testers working on any project. Timesheet a sheet of pre-formatted fields in which daily tasks performed by each person are filled in their individual sheet. The intent of timesheet varies from organization to organization. Some organizations use it for raising invoice from the customer whereas others use it to study the developers pace and engagement with the allocated work. The sheet usually comprises of person’s name, date, project name, plan for the day, and the tasks actually performed against the planned activities. It is not a complex format but it returns valuable information. It can also be termed as daily task sheet of each individual.
Filled timesheet is sent by each developer or tester to their respective leaders routinely. Besides sending it to leader, as per organization directive, a copy may be required to send to HR and/or Accounts department. The frequency may vary from daily or weekly to monthly. It may also be used by accounts person to allocate the resource (developer of tester) to the respective cost centre. In positive sense the purpose of timesheet is not to track the person but to prepare a repository to refer to immediately or later for various purposes. The purposes could be the calculation of total man hours spent on a project, the cost incurred on a project, the engagement/pace/% time of an individual in a project, backlog analysis at any stage during the development, re-allocation of task, requirement analysis etc. It becomes a good tool for HR to find out the vacation trend of an individual. HR or project leader can also schedule the trainings and vacations for each individual based on their timesheet that clearly tells their workload level.
