I'm a big proponent of Agile (mostly XP, mostly anti-Scrum) and have contributed some to the #noestimates "movement".
I don't really mean that nobody should ever estimate anything. I mean that I've never seen useful (fine-grained) estimates anywhere. Here are some of the problems with estimates that I've seen frequently:
I'll note that most of these pit management against the team, instead of working together toward a common cause. Most of the practices also lead to seriously demoralizing the team. And most of the time, the estimates aren't really even taken into account very much.
My advice is to first understand the value of a project before you consider estimating the costs. The estimation at this point will be very rough, so make sure that you have a very wide margin between the expected value and the rough estimate of the cost. If you're pretty certain of the expected value, I'd probably want to make sure I could still be profitable even if it took 3 or 4 times as long to complete as the rough estimate. And if there's uncertainty in the expected value, much more.
Another way to mitigate the risk of throwing money at something that's not going to have positive ROI is to reduce the feedback loop. Order the work so that the tasks are ranked in order of value. (Realistically, you'll have dependencies of tasks to worry about, and should consider effort involved too.) So work on the most valuable feature first -- get that out into production as soon as possible. Once that's done, you can assess if your ROI is positive or not. Keep iterating in this fashion, working on the features that will provide the most value first. Keep assessing your ROI, and stop when the ROI is no longer worth it, compared to other projects the team could be working on.
At a fine-grained level, if you're using story points, I'd ask you to do the math to see if just counting the stories would be as effective at predicting how much will be done over time as using the story points. If so, you can save the time the team spends on estimating stories. I'd still recommend spending time talking about stories so that everyone has a shared understanding of what needs to be done, and to break stories up into a smaller, more manageable size -- with one acceptance criteria per story. Also take a look to see if empirical average cycle time (how long it takes a single story to move from start to finish) might provide you the predictive power just as well as estimates. (I.e. is it bandwidth or latency that really provides the predictive power you're looking for?)
And don't forget Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Excellent, I'll have to check that out.
That is terrible, I've been an OIM consultant for a decade and I've never once run across an implementation that did not use custom connectors (in several cases, exclusively custom connectors).
The out of box connectors are amateurish at best.
Sailpoint has probably the best UI and access certification system around. Unfortunately their provisioning engine is a rebranded BMC Control-SA as I understand it. If that is still the case, no thank you
ForgeRock IDM or MidPoint are cheaper (read: open source) than both. But neither have quite the feature set yet.
I'm an implementer of OIM (10 years now). OIM is an excellent framework for a provisioning tool, but the connectors are terrible (fortunately easy to build your own against the API) and the UI is useless. The most successful OIM implementations I've come across (or built) have been ones that used a custom UI and/or just made everything scriptable. The API is really the saving grace of OIM. It's confusing, but it is powerful.
Sadly, I'm watching the product spiral downhill as of the last several versions.
In one case, the passengers can (and will, it's been done) rise up and fight the attacker.
In the only case there is no recourse, your only option is to sit there and die.
You wouldn't download a car would you?
Also a fair point. I cannot believe is 2015 and Google still hasn't figured this out.
No really an apology for google though, more of a "here is how google royally screwed up in their relationships with carriers that Apple and Microsoft seem to have gotten right".
Depends on the car. Jeep Wranglers are not bad.
Cars also help terrorists. Maybe we should consider restrictions on them too, to make sure they can't be used for terrorism. And guns help terrorists. I certainly don't see the Americans raising a fuss about that. Curiously, the UK doesn't seem to be raising a fuss about that either. Heck, western governments frequently help terrorists. Perhaps we should address that one first.
Regardless of whether a mission expands or contracts, administrative overhead continues to grow at a steady rate.