What do we need to measure for a "new" agile software project that assumes a 5 person team and 6 months to deliver? and why do we need these measures?
218257
The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It's just that simple. You also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning
576915
first get a patent for a new tech .produce it give it to the testers and reanalyse it .register your product. if it is a software release a beta version and look for views then release the original version(i suppose these are logical steps)
380781
you are too vague for estimating, Are you going to manufacture? or buy from a wholesaler? or have someone else make it for you? How large a space do you need ? you will need office staff, warehouse staff, computer systems, software, Phone systemsforklifts, storage systems, Trucking companys need to be contacted and .....  Too many variables . You need a business plan
94877
I would imagine cost might also be a factor ?  Other considerations might include : the size and complexity of the projects you intend to manage, the size and location of your project team, and your current understanding of project management.  \n\nI've included a link to a list of PM software of varying prices - from free to expensive.  Some products, such as TurboProject, even have different levels of the software depending on which features you think you'll need.\n\nThe challenge most people face with project management software is that they don't know how to do project manqament, and so they struggle with the s/w.  Some basic project management theory goes a long way in making the tool easier to use.
582201
do what is best for the client. if the project has nothing to do with a client you should create 2 project plans and send them both to each boss as an attachment with a not that reads something like you boss #1 should work with boss #2 and try to consolidate your conflicting ideas.
186947
a test plan should normally be written once per project (for the whole project end-to-end).  \n\nBut it depends.  There can be good reasons for writing one every phase.
558568
Really, it's a matter of organization and committment.  Are you organized, and do you prioritize?  Are you committed to getting the job done?  It sounds like you are.  Problem one solved.\n\nProblem two is that your tasks are taking longer than you expected.  Have you examined why they are taking longer?  Is it because you did not have all of the information or tools available?  Is it because the tasks were more complex than you originally thought?  Is it because you've allowed interruptions or other time-wasters to interfere?  Do you have a grasp of how long it typically takes you to accomplish certain tasks?\n\nIt does sound like it is a matter of understanding the time needed to complete tasks.  I would recommend the first step is some self-observation. Keep of a log of what you do and when you do it for a week.  Use that information to determine the length of time that is required to accomplish your tasks.  This will provide a better understanding so that the next time, you can commit without having to worry that you have not over-extended yourself.\n\nGood luck!
535405
Hi!\nYou are a team of 4 to 5 people,so investment is not a problem.\n\nTry this out:\n1. Give an ad in a newspaper that you need a 12 or 24 seater ready callcenter capacity. (OR) Call up people who had given ads like "Callcenter capacity available". This will give you an idea about the infrastructure rate that you may require to invest.\n\n2. Contact consultants who are ready to give project. Of course, you will have to give them some lumsome money.\n\n3. Employees is not an problem. You can easily get talented youngsters for a reasonably good pay.\n\nBut, these are the rules:\n"Start with a minimum investment", "Invest in phases",\n"Show good response to your employers"\n"First project is the God for you"
651293
1. About the project\n2. Present Market Scenario & Your Strategy\n3. Production Process\n4. Raw Material Requirement & Availabiltity\n5. Other Resources Required\n6. Project Costing\n7. Detailed Financials spread over a period of say 3 years\n8. Conclusion
383847
There is usually another step in the process - product readiness - it's a separate group of people / different dept.  Prevents those crazy QA guys and gals from taking over the world :)
199183
I was in a system migration project some years ago. Basically you should be able to track success of project during testing phase. So if you are following any standard SDLC say the 5 basic steps of system development, the testing phase will have your evaluation and after go-live you will continue with your audit. You evaluate existing performance against expected results.
601718
Four organizational "paradigms" for software teams: \n\nClosed paradigm: structures teams along a traditional hierarchy of authority \nRandom paradigm: teams are structured loosely and that structure depends on individual initiative of team members. Useful when innovation is needed. \nOpen Pardigm: Heavy communication and consensus-based decision making. Well suited to complex problem solving \nSynchronous paradigm: Based on natural compartmentalization of a problem. Little communication between team members. \n\n\nHere you can found\nhttp://rds.yahoo.com/_ylt=A0geur0x_J9EtgEABy5XNyoA;_ylu=X3oDMTdrOGhzYzUyBEsDZm91citvcmdhbml6YXRpb25hbCtwYXJhZGlnbXMrZm9yK3NvZnR3YXJlK2VuZ2luZWVyaW5nK3RlYW1zJTNCK2Nsb3NlZCUyQytyYW5kb20lMkMrb3BlbithbmQrc3luY2hyb25vdXMEUwMyNzY2Njc5BFNIRQMxBFNIRgMyBFNIVANodHRwJTNBJTJGJTJGd3d3LndpdS5lZHUlMkZ1c2VycyUyRmpqdDEwNyUyRmNzNDkyJTJGUHJlc2VudGF0aW9ucyUyRnByZXNzbWFuLi4uBGNvbG8DZQRsA1dTMQRwb3MDNgRzZWMDc3IEdnRpZAM-/SIG=13mq3v302/EXP=1151421873/**http%3a//www.wiu.edu/users/jjt107/cs492/Presentations/pressman-ch-21-project-management-concepts.ppt\n\n\n\nhttp://rds.yahoo.com/_ylt=A0geur0x_J9EtgEA8i1XNyoA;_ylu=X3oDMTc4ZWhpNTBmBEsDZm91citvcmdhbml6YXRpb25hbCtwYXJhZGlnbXMrZm9yK3NvZnR3YXJlK2VuZ2luZWVyaW5nK3RlYW1zJTNCK2Nsb3NlZCUyQytyYW5kb20lMkMrb3BlbithbmQrc3luY2hyb25vdXMEUwMyNzY2Njc5BFNIRQMxBFNIRgMyBFNIVANVTklUKzErJTNBK0lOVFJPRFVDVElPTitUTytTT0ZUV0FSRStQUk9EVUNUJTJDK0NPTVBPTkVOVFMrQU5EK0NILi4uBGNvbG8DZQRsA1dTMQRwb3MDMwRzZWMDc3IEdnRpZAM-/SIG=11t1qsva9/EXP=1151421873/**http%3a//www.priyankar.4mg.com/softengg.htm\n\n\n\nhttp://rds.yahoo.com/_ylt=A0geur0x_J9EtgEA5C1XNyoA;_ylu=X3oDMTVwczlwY3RlBEsDZm91citvcmdhbml6YXRpb25hbCtwYXJhZGlnbXMrZm9yK3NvZnR3YXJlK2VuZ2luZWVyaW5nK3RlYW1zJTNCK2Nsb3NlZCUyQytyYW5kb20lMkMrb3BlbithbmQrc3luY2hyb25vdXMEUwMyNzY2Njc5BFNIRQMxBFNIRgMyBFNIVANTb2Z0d2FyZStFbmdpbmVlcmluZwRjb2xvA2UEbANXUzEEcG9zAzEEc2VjA3NyBHZ0aWQD/SIG=180hbs5oq/EXP=1151421873/**http%3a//www.blanko.oulu.fi/tiedostot/tenttiarkisto/811335A_20050523.pdf%23search='four%2520organizational%2520paradigms%2520for%2520software%2520engineering%2520teams%253B%2520closed%252C%2520random%252C%2520open%2520and%2520synchronous'
299819
Teamwork is necessary whenever two or more people work towards a common end result. Effective teams:\n *trust one another\n *engage in free and open discussion around ideas\n *commit to decisions and plans of action\n *hold one another accountable for delivering against the plan\n *focus on the achievement of collective results
208286
There's the old "divide up the work and combine them later so that I can go back to sleep" method.  Or the "let's have everyone work on one part of the project at the same time right now so we can discuss" method.\n\nWhen the group is actually together, I'm guessing it's most productive to have an agenda so the team doesn't get sidetracked.  Then, have a sort of group leader make sure everyone contributes and stays on the agenda.
381250
Personally, I won't use any new tech until it's been out for at least a year. That allows time for other people to be the free beta testers for the company and work out the inevitable bugs. This is especially true with Microsoft and Intel, who are notorious for releasing buggy software. Just look how often we have to do 'security updates' with Windows now.
429707
Have a strategy meeting with your 'partner'.  Break down the steps to completion of the project beforehand.  Give them choices of what they would like to take on while you take on another portion of the project.  Schedule a followup meeting to see what the progress of both of your work is.  \nYou have to be careful not to appear too assertive or like you are the boss of the project.  As long as some people know that you will take on the entire project if they slack off - they will slack off.  They have no integrity or work ethics, but they are happy to pick up the paycheck.
39861
That's what I'd assume too.\n\nIT departments have standards, and they want to make sure what's developed runs anywhere (even though you know that's not the case here), is maintainable by anyone, is common, etc...\n\nA good arguement FOR using 5.0 is that if there is some functionality/new methods/etc. that CONSIDERABLY improve performance, reduce programming effort, or reduce maintenance in YOUR PARTICULAR SITUATION, then I would talk to my boss about it.\n\nYou see, standards DON'T change unless there is a good reason to change them.  Saving a lot of money is certainly a reason to consider.\n\nBut, if there is NOT a compelling reason to use 5.0, then I agree with their position.