I've been a project manager for a couple of years now. Still have lots to learn. The basics: - Scope: Define the project and what it's going to deliver. - Requirements: Define the finish line, what's the product or service your project is going to deliver. - ONE BUSINESS OWNER/SPONSER: Who has the purse-strings and will sign off on the completion of the project. - Activities and Milestones: Define what needs to be done and pick off some deliverables on the way to completion, so you can show everyone (and yourself) you're making progress. - Schedule: Put the activities and milestones on the calendar. Do you have people who can complete those activities and deliver the milestones? (Have you factored in vacation time...?)
Some recommended reading: Head First PMP--the PMBOK is dry, Head First made it very accessible. The Art of Project Management, by Scott Berkun--Learned a lot from this book. I come back to it time and again for ideas. Managing Humans, by Michael Lopp--Enjoyable read, got some good ideas. A lot of the chapters in the book can be found at www.randsinrepose.com
Another recommendation: Get a mentor. Check out the local PMI chapter (www.pmi.org) and see if they have a mentoring program.
and worked for Professor Worsey in his lab. It was a great experience--got to blow stuff up, got some machine shop experience, got to work in the mine.
In reference to another thread, I seem to recall that Worsey is a US citizen. It was quite a multi-cultural experience, there was another prof from England, a brief visit from a South African, a Pole and a Russian.
If you meet Worsey (and aren't in mixed company), ask him about sheep and wellies...
Blah, blah, blah, open-source is great
on
McVoy Strikes Back
·
· Score: 1
Sure, having the source code is great for all the reasons enumerated. However, what's not so great is that I'm not in the software development business. My company is not in the software development business. If open-source products will fit the bill, aren't buggy and deliver the needed functionality, then I'll use it. But for applications which are buggy or which need enhancements to make me or my business more productive, I'm going to buy. I paid for it, it's borked, you fix it. I paid for it, if you want me to continue paying for it, I'd like to see these features. Otherwise, I have to accept the burden of fixing bugs or adding enhancements and that makes no business sense.
I think the point the Forbes articles are trying to make and the Sun guy who forwarded one of these articles to me is trying to make is that developers who want to make money are going to look at all the friction that McVoy's experiencing and pick a different platform to target. Which then, in turn, suggests the number of quality open-source or COTS apps will dwindle. Which, for a business, is a factor taken into consideration when evaluating operating system purchases.
Slashdot Mirror
Something to the effect of 'Careless and Imprudent Driving'?
I've been a project manager for a couple of years now. Still have lots to learn. The basics:
- Scope: Define the project and what it's going to deliver.
- Requirements: Define the finish line, what's the product or service your project is going to deliver.
- ONE BUSINESS OWNER/SPONSER: Who has the purse-strings and will sign off on the completion of the project.
- Activities and Milestones: Define what needs to be done and pick off some deliverables on the way to completion, so you can show everyone (and yourself) you're making progress.
- Schedule: Put the activities and milestones on the calendar. Do you have people who can complete those activities and deliver the milestones? (Have you factored in vacation time...?)
Some recommended reading:
Head First PMP--the PMBOK is dry, Head First made it very accessible.
The Art of Project Management, by Scott Berkun--Learned a lot from this book. I come back to it time and again for ideas.
Managing Humans, by Michael Lopp--Enjoyable read, got some good ideas. A lot of the chapters in the book can be found at www.randsinrepose.com
Another recommendation: Get a mentor. Check out the local PMI chapter (www.pmi.org) and see if they have a mentoring program.
Good luck!
and worked for Professor Worsey in his lab. It was a great experience--got to blow stuff up, got some machine shop experience, got to work in the mine.
In reference to another thread, I seem to recall that Worsey is a US citizen. It was quite a multi-cultural experience, there was another prof from England, a brief visit from a South African, a Pole and a Russian.
If you meet Worsey (and aren't in mixed company), ask him about sheep and wellies...
Sure, having the source code is great for all the reasons enumerated. However, what's not so great is that I'm not in the software development business. My company is not in the software development business. If open-source products will fit the bill, aren't buggy and deliver the needed functionality, then I'll use it. But for applications which are buggy or which need enhancements to make me or my business more productive, I'm going to buy. I paid for it, it's borked, you fix it. I paid for it, if you want me to continue paying for it, I'd like to see these features. Otherwise, I have to accept the burden of fixing bugs or adding enhancements and that makes no business sense.
I think the point the Forbes articles are trying to make and the Sun guy who forwarded one of these articles to me is trying to make is that developers who want to make money are going to look at all the friction that McVoy's experiencing and pick a different platform to target. Which then, in turn, suggests the number of quality open-source or COTS apps will dwindle. Which, for a business, is a factor taken into consideration when evaluating operating system purchases.