What would the Sistine Chapel look like if painted today, by an IT department

The artist and the software developer share many things in common. Both deal in pure thought, and abstract ideas. Both try to make them real. Both attempt to constrain complexity, and abstract away the unimportant to the thought.

While the artist attempts to evoke an emotion, or explain the world, the software developer tries to allow another human being to get something done. If looked at from the point of view of accomplishment evoking emotion, maybe the two aren't that different. I could argue that this is a vast gulf between the two as well.

Modern software developers have managers whose theories are historically rooted in the very real worlds of assembly lines, and military necessities. As far from the amorphous world of thought as you can get. Deadlines, measurements, distances, performance, all can be easily measured in reality. We have the tools and they work.

Modern project management has it's roots in ship building, and construction. Fields with firm roots in physics. You can only move the much mass this fast, and this far. It only takes so long to do a weld so big. Everything can be measured, because everything follows the immutable laws of physics.

Which leads us to the question: What would the Sistine Chapel look like if Michelangelo was managed by an MBA, and the whole project overseen by a PMO?

How to accurately estimate projects.....

Most people estimate how long something will take by trying to figure out how long a task will take. Most of the time that works, however for software, it fails miserably. See, it's not about the task, it's about the behavior the user wants. Behavior can't be easily defined the same way a task can be.
Take for instance this task:

Resolve issue with business stuff that's irrelevant (default materials lists were not being created w/ new programs)

The key here is the word issue. It's not defined. So you have to figure it's at least10 hours to get it defined. Then you can get actually implement what they want. Then you have to define what a default materials list is, and what they mean by default. The more people that are involved, the longer that will take. Say another 10 hours at least.
See, the easy part is writing the code. The hard part is figuring out what the heck it's supposed to do. Most project managers, and project management software think that's a task. It's not even a requirement.
Here's another one:

Final notification would be provided to someone indicating that they were something good

Here again the words final notification provide a whole world of unknowns. How will this happen? Will the user have the option to specify the method of notification? That's probably another 10-15 hours of wrangling right there. Then, another 5 hours for the actual content of the notice itself. If it's different formats, you might have another 5 hours wrangling over typography, format etc.
Another one:

Ability for roles within some department to search for people and leave notes

Roles? Which roles? Are they new roles? Search for people? By what SSN? customer ID, email? phone number? Do you know how many ways there are to find someone? Then how do you present the list? How does the user know that they have found the right person? *SIGH* Another 15-20 hours of wrangling.
Here's one more, and one of my favorites:

Business status identified and managed effectively

Manage? Manage? What does that mean? Simple Create/Read/Update/Delete functionality? Do we need a business rules engine? There's a huge difference between managing a 3 person business, and a multi-national corporation. Manage.. really... not even close to being a good requirement.
So what makes a good requirement? Anything that defines behavior. That's not something that can be defined in a single sentence. It's certainly not something that can be defined easily in MS Project, or any other project management software. It's at least a paragraph, probably more.
See not only do you have to define what you want the software to do (how it behaves) when things are good, but also when things go badly. There are usually more things that can go wrong then can go right. Each of those is it's story, it's own behavior.
Project management says you can start when you have all the tasks that need to be accomplished specified. This is just not possible. You're not done when all the tasks have been accomplished. You're done when the software behaves as the user wants.
This is where Behavior Driven Design comes in. It's not a methodology for project management. It's not a silver bullet for all your software project woes. It's a method of doing the hardest thing there is to do in any project: communicate. It focuses the attention of everyone on the project on the two single most important things in any project: Behavior, and communication.
You can find out more at: the wiki article and at the website

Critical Thinking in the corporate world, by the top brA55es

We get a 22 page document on how to fill out a defect report in Jira. This would not be so bad if it was 22 pages of how to describe and detail defects in a coherent way. It was instead 22 pages of work-flow, which is entirely driven by Jira anyway, and therefore does not need documentation.
Instead it was describing the use of 3 fields in order to allow management to do apples-to-apples comparisons of bugs. Only an MBA (Massively Bad Advice) could come up with something so incredibly asinine. Bugs, like real estate are unique. A bug in one application is not the same as a bug in another application.
What they mean is that they want a way to determine which bugs they want to get rid of, and which ones they want to keep. This means that by definition defective software is acceptable. Which means that at my employer, quality is not a primary concern.
Yes folks, MBA's think defective software is acceptable to deliver to the customer.
Is there any wonder why I call being made a manager, a demotion.......

One to Many relationship in liftweb

Most of the other examples don't follow all the way through, leaving you at the "Oh gee, the mapping is done, now how do I get to select the many". My example is not to show the One to Many where the Many are dependant on the one, but rather choices that the one can belong to the one. So for instance you have a Party which has a many to many relationship with PartyType. However, a Party can have different types at different times, so you need a one to many from the party to some intermediate class (we'll call it PartyClassification), and then from PartyClassification to Party Type.
Something this: Party[1]->[N]PartyClassification[N]<-[1]PartyType.
The Party[1]->[N]PartyClassification part is fairly easy to do, and I'll cover it later. However the PartyClassification[N]<-[1]PartyType is more interesting. You can't create a PartyClassification without a PartyType, and you have to present the user with a selection of PartyTypes that the PartyClassification can have.
Now, for the example I'm going to use One[1]->[N]Many as the actual names. I could use PartyClassification and PartyType, however whenever I follow examples with "real" names, I sometimes forget which is the many, and which is the one. I'll assume the same happens to you, and keep it simple.
So we start with a fresh mvn archetype install.

Selling a customer experience not a product or service

http://www.venturecompany.com/opinions/files/serviceforce_is_a_big_deal.html

Business Plans

http://www.pehub.com/36689/study-finds-business-plans-a-waste-of-time/
I've heard this before, from some of the VC blogs I follow. They use the plan as a filter for people they don't know. Same for angel investors. I think they understand that the plan is only good until you open your doors, and then you have to adjust as you go, making the plan fairly obsolete fairly quickly.
In Art of the Start, Guy Kawasaki says there are 5 things you MUST accomplish as an entrepeneur:
1) Make Meaning
If you're ogarnization never existed, the world would be worse off because _________________________________
2) Make Mantra - as opposed to a mission statement
In 10 words or less write your organizations mantra:
3) Get Going
Just go do it. Now please :)
4) Define your Busines Model

1. Calculate your monthly costs to operate your organization
2. Calculate the gross profit of each unit of your product
3. Divide step 1 by the results of step 2
4. Ask a few women if you have a chance of selling that many units. If you don't , no business model

5) Weave a MAT - Milestones, Assumptions and Tasks
Okay, this is a big section.. buy the book!

Standout in a crowd

Watch this link
Okay, so the guy is a bit.. aggressive but is he wrong? No, I don't think so .
Coll Business Card Designs
Super hero Cards
Show Off Cards