The collaboration corroboration.
Of late during the course of my work I have noticed more and more prospects with queries on social collaboration /intranets. Everyone seems to want a “facebook” for their organization. And why not! After all, effectiveness and efficiency is brought out through team effort. Reports on the same suggest that-
- Social collaboration tools are on the rise in the workplace. Of those people who use these tools at work, 59% say that their usage has increased over the last year.
- 91% of respondents say that email remains their most frequently used tool for inter- and intra-company collaboration.
The greater use of social software together and strong continued use of email is hard to reconcile given that email and Web 2.0 collaboration still sit in separate silos. End users definitely see a place of social collaboration tools in the workplace. However, the breadth of reach of these tools and user adaption has impacted the usefulness of these tools. A survey suggests that 63% think the biggest problem weakness of social collaboration tools is that their co-workers don’t use the same system (i.e., they use email only).Cars have “crumple zones” to absorb the impact of opposing forces; sadly, the crumple zone here is user satisfaction and efficiency.
A new model with zero compromise is the need. We are doing disservice to our customers by forcing them to trade off the benefits of one tool vs. another. Users should be able to reach any person or group using their preferred method of collaboration and have easy access to content regardless of where it was created—bridging the gap that currently exists between email and social collaboration.
Let me know your thoughts on the topic. How do you think email should evolve in order to accommodate users of social collaboration tools? I’m curious.
Not a Freeware
Open source. This term is perceived differently by different users. I have come across a number of business and technical users that think that since software falls under the Open Source tag, it is a freeware. This is a misconception. There is a huge, commendable Open Source community that works consistently, unstoppably towards enhancing the existing tools and technologies. However, most open source vendors have a subscription model and an attached cost. The cost entails the user to various levels of tested and certified versions of software, compatibility and upgrade advice, support benefits, free upgrades, service packs etc.
These benefits are not a part of the community edition of the software. The subscription to the enterprise edition of the software makes available the support directly from the creators of the software This cost however is a fraction of the cost incurred on procuring a propriety software license. Several whitepapers are available reiterating this fact. E.g., http://www.ciol.com/Developer/Open-Source/News-Reports/Save-up-to-96pc-on-ECM-with-Open-Source-stack/41208113377/0/
Open soucre adoption – Concerns
In a few years, Open Source has grown from a new development and licensing model supported by individuals or small groups to a major technology ecosystem, at the basis of the Internet, software-as-a-service and cloud revolutions. It is not only becoming ‘the hidden backbone of the software industry’. It is now at the core of business strategies from most major IT players, from software vendors to integrators and SaaS providers. Will maturity come with a change of culture and perspective? On the other side, large Open Source-based players are adopting dual licensing models that would have been, in the past, clearly labelled as proprietary. Many new comers argue that this debate may be out of date, with cloud and the service being the future of the software. As a result, the old Proprietary vs. Open Source business antagonism is rapidly blurring into a large spectrum of models. Does it lead to convergence or confusion?
Time and again we come across concerns around open source adoption. The most pertinent ones are:
| Security of the software |
61% |
| Service/ support availability |
51% |
| Total cost of ownership (TCO) |
43% |
| IP/ legal issues |
30% |
| Viability of the OSS communities |
27% |
| Complexity/ difficulty of adoption |
27% |
| Product immaturity |
20% |
Old School to Open – Change of guard
I have been working with a leading Open Source ECM SI for a while now as a business analyst and a pre-sales consultant. It’s been a very interesting phase in terms of the sort of concerns the prospects have, convey and our concern alleviation methods.
Open source is increasingly mainstream, but getting value from it, whether you’re a vendor or buyer, is still more art than science. Open source has thrived throughout the recession, providing low-cost, high-value solutions that appeal to CIOs faced with tight budgets. Red Hat and other open source companies have helped their customers weather the storm of the global recession. With the economic recovery now well underway, the time is ripe to re-examine plans for technology deployments as many companies start investing in new IT projects.
Businesses have had decades of experience in acquiring software directly, on hardware, in services engagements, and through system integrators. The interoperability, flexibility, affordability and countless other benefits that open source and open standards deliver will be key as companies look for IT solutions that solve 21st century business problems. Customers want to leverage emerging technologies like cloud computing, virtualization and java. Old school technology practices – fraught with hidden lock-in and expense – can’t compete with the value that open source delivers.
As more and more organizations consider using open source, it’s important to uniformly hold all acquired software to high standards regarding quality, security, performance, and value for money spent in acquisition, support, and maintenance. Additionally, open source software adds questions about inclusiveness, governance, and longevity of communities.
Use cases and Beyond
REDUCE REUSE RECYCLE!! Happy Earth day folks!
Storyboarding is a great way to REDUCE your change request management cycle. It’s a good way to gather requirements and allows you to visualize possible use cases and enables stakeholders a walk-through through conceptual screens and easily comprehend the proposed system.
As long as the focus is on core requirements in the early phase of software development, it works very well. However, to see more details, especially user interface, we have to find other techniques and this leads to a lot of added documentation and sign-off nightmares. The engineering process turns time-consuming as it requires catering to change requests. Also, use cases without UI information are not so easy for business users to understand.
Business users often get more ideas when they see prototypes or mock-up screens, and ask for change in the requirements. Lo and Behold! Not only has your requirements refining and making requirements better started, but you have already started designing (and implementing testing sometimes), so it can definitely have a big impact. Once you start this practice, you will have a lot of ideas and mock ups you can REUSE!
A question often asked to me even in the early stages is how the screen looks, to understand the system we propose. So, I explain by drawing some simple wireframes on white board. Some elements and text messages are enough to express the system’s behavior. This sort of visualization helps get business users on the same page, and helps me get more and relevant feedback.
Vision, Use Case, Storyboard
Use case techniques sometimes require us to describe and manage detail specifications and UI information separately, and maintenance of the documents can be difficult. I don’t recommend skipping the creation of use cases in your process. I prefer focusing on core requirements initially to find what business users want, then start storyboarding to refine the use cases. If you start storyboarding from the beginning, your business may be confused due to too much information, unless your application is small. RECYCLE the information you have through the story boarding iterations and you will have a happy client who is clearer about what he wants and what he is going to get!
Requirements Definition – Are we Done Yet? – Conclusion
Ludwig Wittgenstein stated “The riddle does not exist. If the question can be put at all, then it can also be answered.”
I suspect that Ludwig ever had to deal with requirements!!! You will never be done with requirements because things change – businesses change, technology changes, competition changes, people change. And, it is because of this inevitable change I feel that the question “When do we know we are done?” cannot be answered with 100% confidence.
However, if you assess requirement completeness within the confines of:
- your defined scope,
- the developed models
- your organization’s comprehensive requirements document templates; and
- you enlist your stakeholders’ participation to confirm a comprehensive and correct set of requirements; and
- you evaluate the potential costs of future changes with that required to foresee every requirement,
Then you can answer that question we often hear during the requirements phase – are we done yet?
The answer?? No we are not done yet but we are done enough to proceed to design.
Requirement Definition – Are we Done Yet? – Part 4
Criterion 4 : Benefit
Regardless of what you do to validate the requirements phase, you still have those “hand-wringers” that refuse to sign-off for fear you are missing some really important requirements. You think you have all the requirements, the majority of the stakeholders think that you have all the requirements, and you, and probably everybody else, secretly want a single one indicator that screams that you have all the requirements and are ready to baseline and start designing. Unfortunately, no such indicator exists. If you are in a quandary about whether you are done with requirements or not ask yourself this question…
What will cost less – potential downstream changes because I forgot some requirements or the time, schedule and resource investment required to make sure that I have defined every possible requirement?
A word of caution; there are people who are on the other side of the spectrum from the hand-wringers…I call these people the Schedule Mongers. Schedule Mongers are those who insist on starting the next phase of a project irrespective of the status of the current phase because “see it’s on the schedule and if it’s on the schedule, we haveto start!!” When assessing the readiness to move to Design, the Schedule Monger does not necessarily care if the requirements are done and is oblivious to, or in denial of, the fact that starting without a good set of requirements will definitely cause a slip to the product delivery, add costs, and probably result in unsatisfied customers. Beware! The Schedule Monger and know that the question you ask about the risk (cost) of proceeding, or not, is just as applicable when dealing with the Schedule Monger as it is with the hand-wringer.
Requirement Definition – Are we Done Yet? – Part 3
Criterion 3: Look at Your Models
A variety of practices exist around creating models, to verify that you have a complete set of requirements.. They can be developed using business process, object-oriented, or structured analysis techniques amongst others. When I speak of models, I am referring to Activity Diagrams, Swim Lane Diagrams, Flowcharts, DFDs, ERDs and the like. I am a staunch advocate of modeling. Developing models is a great way to engage the stakeholder and get them to communicate their requirements in a non-intimidating and comprehensive way. By non-intimidating I mean- how scary is it to draw a picture to graphically present what is done today or that which is wanted in the future? Comprehensive? With a picture, you can easily validate steps and decision points and identify errors and omissions.
To assess the completeness of my requirements, I prefer to work from both my current state and future state diagrams. By analyzing both states, I increase my confidence level that I have the requirements to sustain existing function, performance, and compliance needs as well as define the requirements essential to achieve the defined Vision and scope.
Requirements Definition – Are we done yet? – Part 2
Criterion 2 – Check your template
Did you use a standard outline or template for your requirements? A number of organizations have developed standard templates for different type of projects; software projects, hardware projects , maintenance, upgrades, etc. A well-constructed template lists the different types of requirements that are typical for the various types of projects/products of an organization. So, if you do use a template, make sure that all relevant requirements have been gathered and documented, the checklist appropriately ticked.
Excuse me for stating the obvious but a big hole in your template is a good indicator of missing requirements.
Analysing Businesses 
