We have been rolling out internal instant messaging at the Big Green N for a few months now in a grass roots/guerilla technique. It has been a rousing success.
One of the major risks of using the publicly available tools (Yahoo, GTalk, MSN) is that all your corporate data is flowing over the public internet. Unencrypted and ready to be analyzed by the purveyors of those networks. Any reasonably company should realize that putting corporate data over an insecure public network is akin to letting competitors have a peek at your future product strategy.
This is not sensible.
When an organization has awareness of all avenues of communication their employees can use they can relax knowing that collaboration is still occurring, but within the rules defined by the organization. No public virus laden spam-bots sending messages, annoying your employees, while not denying the edge that instant messaging and presence notification provides.
One of the initiatives I have taken upon myself while under the N has been to roll out secure internal instant messaging. The major requirements of the system was for it to be open (as in standards), extensible (as in the programmable sense), architecturally compliant (Java & Oracle), scalable and finally - easy to administrate and use (less end user training and better cross-company adoption).
I was just reading over on the Alfresco blog some intersting notes about how their document/content management system works - written by John Newton. There is a very helpful discussion on XQuery versus XPath versus SQL that required me to dust off some of my XML and SQL kung-fu.
That was not the main focus of this post; of interest was a link to a PDF that discussed the differences between successful and unsuccessful projects. They took a random sampling of projects and determined there were a couple of key elements to maintaining a successful project.
Now, some of these elements may seem obvious but the crux of the issue is that in private companies these don't exist; or I should say that some of the companies I have worked at don't.
The Version Control and Bug Tracking points are "duh". You can't reliably build software if you don't know who has changed what, when, and why they did it. The classic "Where did this code come from" is eliminated if you can point the big hairy finger of blame/congratulations at Billy. Documentation is another point, how well do you write up the internals of any project you work on? If someone else had to take over your project do you use the typical "Read the Code" excuse for your laziness or can you dump a tight, well formatted document on your overworked colleague?
The suprising, yet subtle, requirement of a successful project is the mailing list aspect. In the report, they state that developers are able to look to the mailing list for information they require (if the documentation is lacking). I have to agree that in many of my Google searches I end up trolling mailing lists for configuration tweaks or install issues. But, mailing lists are typically for distributed teams -- do you replicate this kind of communication in a closed, co-located environment? I would say it is worth a shot. This goes heavily against my desire to eliminate email in an office environment but you can setup elaborate filtering rules to mangage the influx; allowing you to Get Things Done.
But, what are your other choices to a local mailing list solution?
Wiki - too random and likely to be out of date unless a very strict hierarchy is enforced/created.
Blogs - one way communication channel. Comments too quickly become unreadable.
Forums - two way communication channels. Comments can get cluttered rather quickly.
Maybe my declaration of the death of email is a little too early yet...
Everyone has process in their daily job, my question is:
- have you written it down for someone else to examine and scrutinize
- have you examined it for efficiencies (good or bad)
- do you have redundant steps that are holding back your potential
There are Amazon books a plenty on process and improvement but most of them can be quickly boiled down to "Do the right amount of work, the right way, right on time". The devil is in the details of creating a working product on schedule, on budget without causing employee flame-out.
I have worked at many companies over the years and seen many different styles of development and/or process and those companies attempts to streamline their process and improve their Cost/Quality/Schedule. There have been some successes but more often than not the problems remained in another nook to be ferreted out.
In one company it was introducing an Issue Tracking system, in another company I wrote test generation code. Each of these helped in improving different elements of the development process, but neither was a "silver bullet". They helped but did not fix the entire problem.
Software is evil this way. No matter how much you improve your process, problems will pop-up elsewhere. Its like to hold on to an ice cube, things just melt away. Constant improvement should be your mantra, but it is very hard to keep focussed when there are bills to pay and clients to impress.
So, what is your process?
When you start a project do you follow a hardened set of steps, improving as you go or do you treat each project as a unique entity with unique steps to avoid the last projects mis-steps.
If you follow the latter do you get better quality? Are your customers happy with the wild ride they embrace with your company?
If you follow the former do you have better repeatability? Do your customers resent the lack of individuality and lack of customization for their situation?
I really am curious, in the other small companies out there, what has worked better for you (and your industry): the same process no matter the contract or a unique approach to each contract as dictated by the customer's needs?
Discuss!
