SharePoint Blog Window out of the box
I think we can agree that we want to be in the Cloud but not of the Cloud. The key problem I find in delivery of IT solutions is what some call the Geek Gap. The business can't understand its IT experts or consultants and tends to enter in to a adversarial relationship with talented developers. Developers are annoyed at the business and tend to secure their departments and positions. Geek is Geek and Chic is Chic and never the two shall meet. Or can they?
This problem just seems to get worse and worse as new options come on the table. Should you go virtual? Should you go 64 bit? Should you go SaaS or not?
Well these questions are beyond the scope of a blog post, but I think I can make some recommendations to both IT and business to insure that you confront the Cloud in a logical, controlled fashion that delivers cost savings.
1. Use-Cases just look stupid
For some reason no one seems happy with use-cases at first. When I first saw them I laughed and figured they were a PM waste of time. I was wrong. Statements like "the user opens an existing word document", "the user makes edits to the existing word document","the user saves the world document", "the user publishes a new version of the world document" may seem childish but they are far more useful than most people understand.
Firstly use cases and use-case stories give you a controlled way to record requirements in a form that can go to development, no other framework that I have seen can say that. Also use cases-can structure projects from requirements to testing and acceptance. Use-cases can give you documents that can hold up in court and to which positive assertions can be made that requirements were meet.
If you consultants don't use or don't know about use-cases maybe you need new consultants. Maybe I am a bit out of bounds here, but I would say that if anyone argues against use cases they are ALWAYS wrong. No project is too small or two routine to NOT use use cases. In fact a very standard project gives you the opportunity to straighten and rationalise your use cases. If you are in IT you should have the use-cases meet by you solutions at hand to start with.
2. Keep it process and not people
In the end of a project there should never be anything done on the basis of one person's opinion. Everything should have a process and set of justifications.
3. Demand costs be justified in IT
Though it sounds idiotic it is essential to insure that extra costs and risks are justified on something more than a blanket "best practice." For example if you are going virtual in VMWare ESX and your companies IT staff insist on deploying Databases in hardware you might want to first test if you can meet your objectives with virtual machines. I rarely see this kind of testing done, but it is no problem to first build a VMware SharePoint farm and then swap out the virtual machines for hardware if it does not perform in a POC or UAT.
4. Clearly define deliverable
Everyone knows what objects are going to be delivered when. Every object delivered has a plan for it. Remember that often its around documents and training that misunderstandings develop in to project failures for all involved. Docuements and meetings are deliverables just like working systems. Remember management is a product to be included.
5. Divide and Conquer
Break projects up in to smaller pieces and parts. Isolated risky development projects and deadlines from time boxed activities like requirements articulation, documentation, and hand-off.
6. Assume Problems
Try to develop a culture that understands that problem happen. Often people are afraid to admit difficulties and problems get swept under the rub until they balloon. Keeping it to processes and not people will help in this one a great deal.
No comments:
Post a Comment