Post #365,853
11/6/12 4:12:11 PM
|
Agile portfolio management
(BTW, there's no "Business of software" forum here.)
We're switching to Agile development. New tools, actual training, buy-in from the very top. All cool. But the CEO is asking for information about portfolio/program management. ie: How do we decide what to build?
We're trying to get to a point where, when sales comes in with a prospective customer, we estimate what it will cost to build what they want before committing to it. But of course Agile says you don't try to estimate.
So if we don't estimate, how do we know which opportunity to pursue?
--
Drew
|
Post #365,879
11/7/12 4:20:17 AM
|
"Agile" is very trusting
It may work for a group of coders who are employees dedicated to a company, and are thrown projects, but it won't do shit for contract programming if you need to have waterfall level breakdowns that in turn feed to estimated work points.
You need to have project types. X screens with Y fields with Z level of complexity for implementation. Q network nodes combined with S servers times C clients which in turn will drive up your complexity, timing issues and add to your pad factor. Add in L layers of management overhead review times and associated cost for redoing nonrequired cosmetic changes that allow the VPs to put their stamp on the visual interface.
I can go on and on and on. Anyone who truly thinks they can estimate a project without having years of experience in the particular field and implementation type is full of shit. You will be winging it for quite a while.
|
Post #365,884
11/7/12 7:29:49 AM
|
Yeah, "we" suck at estimating
By which I mean the non-technical (but thinks he is) CEO gives prospective customers estimates for when we can have them in production before the technical team has even seen the requirements.
We're trying to at least get to a point where we can decide whether a given opportunity is even worth what it will cost to do it.
--
Drew
|
Post #365,937
11/7/12 7:09:07 PM
|
Opportunity
Obviously this teams needs a strong manager to whip them into shape to perform up to the CEO obviously perfectly realistic assumptions.
Take the job. Make sure it is a serious raise. Then once you are in the position, use it to educate the CEO 1-1 and also go on sales calls. Do ANYTHING you can to reduce the CEO's burden, but never cut him out of the decision loop. Hell, go on sales calls all by yourself if that is what it takes.
5 years later you get the company when he retires.
|
Post #365,939
11/7/12 7:28:51 PM
|
You really should get that book in your head onto paper. :-)
|
Post #365,942
11/7/12 8:01:12 PM
|
Yup
I've already pitched the VP of sales on the idea of bringing me on sales calls. That was when I was reporting to the CIO. (Oops, when I said CEO I meant CIO. Yes, the CIO is non-technical but doesn't realize it.) Now that I'm not, things are changing. I'm on the initial phone calls at least. Might be doing a site visit soon for a new prospect.
--
Drew
|
Post #365,968
11/8/12 11:31:07 AM
|
Good. Perfect path
Complex projects are easy to pitch but impossible to fulfill based on the easy pitch. On the other hand, with your support, maybe they can identify more/better prospects. Even before they do anything, get a list of possible customers together and forward them to the sales guy.
Create leads. Nothing will get you noticed faster than that.
|
Post #366,116
11/10/12 11:39:52 PM
|
Just picked up a book on the subject today.
"Agile Estimating and Planning" by Mike Cohn. It was recommended to me by my brother, who's a big Agile guy. I just got it today, so haven't even cracked the cover, but I'll let you know what I think after I've read it.
Amazon link. I see it's available for Kindle, too.
http://www.amazon.co...hn/dp/0131479415/
|
