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.
Jul 6 2009 10:00AM GMT
Posted by: Jaideep
Quality Assurance,
Software tester,
software testing,
Project Planning,
Test Plan,
test case,
product analysis,
customer requirement analysis,
product functionality,
software functionality,
software documentation,
software document,
test result,
test performance,
software performance,
testing process,
quality analyst,
QC,
QA,
quality control,
load testing,
performance testing,
functional testing,
security testing,
test coverage,
software build,
software,
analysis,
functionality
A software tester evaluates software based on certain parameters. These parameters are set as per product, customer and organization requirements. Testing could be just of functional features or include load, performance and security. For any parameters a tester has to work as quality analyst to understand requirements, features and accordingly build test cases and perform test. This is the quality control part. On quality assurance front the quality team has to build standards for requirement freezing, planning, development, implementation and post implementation phases of a project.
A software tester at various stages of a project gets on to the job of a Quality Analyst by performing following tasks:
Analysis of customer requirements: The first and foremost analysis required is that of the customer requirements to ascertain if it is complete, detailed and free from any confusions, ambiguities or equivocalness. Any flaw in requirements will certainly lead to a big disaster at a later stage. Unclear requirements are not difficult to build, but are difficult to manage. Every requirement should be in black and white. Each line should be very clearly documented such there should be nothing hidden between the lines.
Analysis of Product Functionality: Requirements documented and product built has to go hand in hand. It should not happen that requirements and product speak differently even a single line. Usually while testing functionality of a product, tester forgets to refer to requirements documented, or asks developer about the functionality. The developer will certainly explain him the functionality he has built not what exactly has been mentioned in the requirements document. If this happens, it will certainly cause a big blast at implementation or acceptance stage.
Analysis of Product related documents: There are many documents prepared during the project. Some are meant for internal use, some are prepared for customer. All these documents need to be inspected thoroughly and neatly.
Analysis of test results: Test cases are built to perform tests resulting in bugs report or test results report. A thorough scan is must to ensure complete coverage and thorough testing. The report should be detailed in all respects in terms of clarity and coverage.
Analysis of Testing Process: The testing process once establishes need to be revisited again and again to improve further at every go. Once established does not mean it is ultimate and best. Improvement has always a scope howsoever best your process or product is.
Jun 29 2009 10:00AM GMT
Posted by: Jaideep
Software Project,
Project Management,
outsourcing,
requirement analysis,
requirement gathering,
requirement freezing,
software design,
software development,
software testing,
documentation,
project implementation,
training,
handholding,
post implementation,
Project Planning,
project control,
project execution,
project component,
project phase,
project offload,
project outsource
We learnt in earlier two posts about the strategic decision of a management to outsource a complete project or part(s) of a project depending on certain factors, and the factors respectively. In this post let us see at the various components of a project that are most widely outsourced or otherwise we can say these are the components of a project which can be outsourced. It is very less often that a project awarded to a company is totally outsourced.
We are talking about outsourcing an activity of a software project. The most important components of a software project can be listed as:
Requirement analysis, gathering and freezing
Design, development and testing
Documentation
Implementation, training and hand-holding
Post implementation support
These can further be broken into various sub-components under each component thereby creating a tree like structure to have a bird’s eye view of any project. Planning and execution for each phase or component comes next with control everywhere.
Outsourcing mainly is the resultant of constraints in an organization.
Apr 27 2009 10:06AM GMT
Posted by: Jaideep
Project Management,
project overrun,
project implementation,
Software Project,
software implementation,
Project Plan,
Project Planning,
project manager,
project organization,
project monitoring,
overseas project,
domestic project
A classic scenario happened in an organization recently as told to me by a project manager of that organization engaged in software development and implementations.
It is related to project overrun.
A new project started with a set of requirements from a customer for development and implementation. It was an overseas project so project cost was comparatively higher than the domestic project. The respective teams for business requirements, development, configuration and implementation were formed. All went well till the implementation phase. The implementation team was ready to take the charge for on-site visit with the product to launch there.
The implementation phase planned was 4 months. Somehow due to a mix of reasons, it took 18 months to complete the implementation.
The team came back after successful implementation. The customer paid the full project cost as was accepted upon in the beginning.
The project was declared as successful without any overrun. For overrun cost was taken the criteria and since full cost was recovered, it was treated as not overrun project.
Is that right?
Throwing some points to ponder upon:
The cost that had to come 14 months back came now.
The team that has to return 14 months back arrived now.
In this period of 14 months atleast 3.5 projects of similar nature and size would have been completed.
The project manager is over-optimistic.
Project monitoring was very poor.
Etc.
Etc.
Etc.
Apr 24 2009 10:06AM GMT
Posted by: Jaideep
Project Management,
Software Project,
project momentum,
project velocity,
project cost,
project time,
project organization,
customer engagement,
project sign-off,
project closure,
project training,
Project Plan,
Project Planning,
management involvement
Project overrun is simply a project crossing its boundaries set by the organization. These boundaries may vary from organization to organization depending on how they blindly or how over-extensively (both extremes) they want to look at it.
5 ways to control project overrun could be:
1. Requirements: With any change in requirements from customer, effort estimation and change in plan is important to drive the project in right direction.
2. Customer engagement: At customer site (or earlier as and when customer involvement is required) if customer project team is not justifiably involved in project by means of specifying requirements, providing master inputs, in training, timely sign-offs at various stages, hands-on exposures, etc. effects project drastically and plan may go haywired, without anybody’s accountability to prove, if alarm is not raised well in time.
3. Milestones: If appropriate milestones are not identified and monitored at every stage of the project, it affects the project finish off in time.
4. Management involvement: If management let the project go off without their involvement in it, it has high chances to overrun.
5. Celebrations: No celebrations of achievements during the project can decelerate the tempo and momentum of the team at both ends to finish off the project in time.
Apr 22 2009 9:51AM GMT
Posted by: Jaideep
Project Plan,
Project Planning,
Software Project,
project overrun,
project acceptance,
project organization,
customer requirements,
software requirements,
Project Management,
project closure,
project manpower management,
project cost,
project timeline,
project timeframe
All projects are prone to overrun. An overrun acceptance is directly proportional to an organization’s fault absorption capacity. Accordingly the definition of overrun is framed to demonstrate an overrun project as rightly completed project.
5 myths about Project Overrun could be:
5. Planning: After the initial plan is made, customer requirements have shrunk but it is good not to revise the plan to achieve in-time project closure (or even earlier).
4. Manpower: Project Plan is made after which additional manpower is inducted in the project, but no need to revise the plan.
3. Cost: Customer is ready to pay the full payment to complete the project, even if it overshoots the timeframe decided as per plan.
2. Time: A project had to complete in 5 months, but it took 10 months to complete. Imagine the manpower engaged in this project that could have finished another project if this project finished in time.
1. Customer: Customer is not able to cope up with plan but not ready to pay for extra efforts being done by the project team on behalf of customer thereby overshooting cost and time. We have a valid reason for this overshoot.
