Approaches that are either too general or too specific can easily overwhelm practitioners—and derail budgets. Fresh from recent experiences with two large-scale redesigns, Katie Kovalcin suggests that flexibility and open communication can transform all team members into what she calls “80/20 practitioners,” creating a more effective balance of time and resources.
There is a decision doc managers need to make all the time: balance savings today against expenses tomorrow; balance constantly patching a doc with tearing the whole thing down and starting anew. My solution to fixing my fence was the exact same I would have taken to patching a doc.
Uncertainty is the only certainty of a freelancer’s life, but it’s also a problem that afflicts wage slaves, as I learned during the first 15 years of my career. Something unexpected always seems to be popping up, disrupting our carefully crafted plans and leading to long days and late nights. Fortunately, there are ways to make life less uncertain than it might otherwise be, and each involves actively managing our schedules rather than waiting for others to define them for us. Active schedule management involves three types of activity.
Scrum, the new development methodology in the Agile development family, is fast gaining acceptance in software development. But how can writers, who have little or no experience in any of the incremental development models, adjust to this methodology? And, how does the Documentation Development Life Cycle (DDLC) change in Scrum?
eXtreme Programming and other agile processes provide a middle ground between chaos and over-elaborate processes sometimes referred to as 'death by documentation'. A particular attrtactive aspect of the agile approach for many teams is its willingness to accomodate change no matter how advanced development might be. However, this very flexibility can cause user interface design issues and ensuing usability problems. Adopting a user-centered approach to user interface design can address these issues, as the following simulated conversation between a user-centered design consultant and an XP team leader will explain.
Much effort is focused, on the selection and subsequent implementation of a content management system (CMS). While it is obviously vital to ensure that the initial implementation project is successful, this is only the beginning of an ongoing commitment to growing and enhancing the use of content management throughout the organisation.
Agile methods aim to overcome usability barriers in traditional development, but pose new threats to user experience quality. By modifying Agile approaches, however, many companies have realized the benefits without the pain.
Software development methods seem to change more often than the seasons, and just when information development professionals are familiar with one approach a new one comes along. One method that has received wide acceptance and seems to have some staying power, however, is the Agile software development method. As described by the Agile Manifesto (2001), Agile software development is: a group of software development methodologies; based on iterative and incremental development; solutions evolve through collaboration of cross-functional teams.
Can project management be an art? Has Berkun truly created a jargon-free guide for the whole project team? Kalbach leads us through the high-level tasks and the major milestones of this new book, while keeping us on task.
I know some people see asking questions as a sign of weakness or insecurity (and believe others will view them that way), and that asking questions can produce answers we don’t want to hear. Both of those possible results pale in comparison to the potential good that just sitting down and asking questions can produce.
With more and more companies adopting the Darwin Information Typing Architecture, Baril discusses how to choose a compatible content management system that also supports your company's processes.
First came the primordial soup. Thousands of relatively simple single-celled web sites appeared on the scene, and each one was quickly claimed by a multi-functional organism called a "webmaster." A symbiotic relationship quickly became apparent. Webmaster fed web site. Web site got bigger and more important. So did the role of the webmaster. Life was good. Then, bad things started to happen. The size and complexity and importance of the web sites began to spiral out of control. Mutations started cropping up. Strange new organisms with names like interaction designer, usability engineer, customer experience analyst, and information architect began competing with the webmaster and each other for responsibilities and rewards. Equilibrium had been punctuated and we entered the current era of rapid speciation and specialization.
A two-person bilingual writing team enabled a software application development group to produce on-line documentation and a user guide simultaneously in two languages. Team writing in an international environment requires detailed planning, constant monitoring, and continuous communication in order to succeed.
This paper identifies challenges for obtaining managerial buy-in for a user-centered design process using performance tasks. Initially, it presents lessons learned from a case study. Next, it provides strategies (leadership, persuasion, organizational conflict, active listening, and teamwork) for obtaining buy-in from work team and their constituencies. Last, it concludes with recommendations for obtaining buy-in from managers.
I will be blogging about team creativity over the next few weeks, to share ideas and best practices for helping your team achieve their creative peak. Maybe you will find an idea that you can use to help your team work differently. But first, let’s look at the symptoms and causes of team complacency.
From a software development viewpoint, model-driven architecture (MDA) encourages efficient use of system models. It also encourages reusing best practices as families of systems are produced. One of the main aims of MDA is to separate design from architecture, which places the business analyst in a unique and potentially powerful position within the organization. Learn how you as a business analyst can take an active role in this type of architecture.
The non-writer who takes over the documentation can act like a bull in a China closet, copying and pasting from Word, mixing styles, not understanding the setup, basically wrecking the consistency, the bullet levels, the formatting. If you see the documentation later and find that the client has added steps without numbers, included text that breaks every rule in the style guide, won’t that be unnerving? Yes, it will make you want to jump out the window.
Scrum is a proven, Agile software management method that has been widely adopted by organizations seeking to reliably deliver higher quality software. Scrum is a simple process: it has a small set of interrelated practices and rules, is not overly prescriptive, can be learned quickly and produces productivity gains almost immediately.
Provides a brief overview of the Scrum method as well as 'playbook' of guidelines and tactics for enterprise-wide adoption of Scrum.
From early 1993 through July of 1994, three STC chapters jointly managed a research project on Technical Communication in Western Canada. Based in Winnipeg, Calgary and Vancouver, the managers were thousands of miles apart, relative strangers and simultaneously engaged in running their own businesses. In this volunteer assignment, they involved committees within their own chapters. As team building and collaborative arrangements become more prevalent in technical communications projects, it can be instructive to look at how such a farflung research project fared. We will relate this experience briefly to some research results reported in Technical Communication.
Every project has its own unique set of 'opportunities'--also known as challenges. Many of these challenges relate not to the quality of our work, but rather to the communication of our ideas. Often in the course of design, you must communicate complicated concepts to a non-technical (and often uninterested) project sponsor, client, or stakeholder. So how do you capture their interest, get their understanding and buy-in, and finally move on?