Basic math – a negative plus a negative cannot equal a positive. Sometimes, depending on how large the negative is, it may take quite a few positives to break even. This idea applies equally well to workplace negativity. Some negatives at work are actually a positive (i.e., constructive criticism). Constructive criticism is a positive if used for productive means. It helps the originator voice their disapproval or lack of support in a manner that allows people to respond in a positive, non-accusatory manner. Everyone can then work together to move forward with the positive goal of accomplishing the tasks involved. Although this is the ideal process, it isn't necessarily the way it happens. Many factors create negativity in the workplace: Negativity exacts a price not only at the personnel level but can be very costly to the employer too. Employees whether directly or indirectly involved in the 'line of fire' may become depressed, feeling sick and leading to absences. Employees avoid working with others as the dread of negative attitudes and confrontation looms. As employee attitudes fail, it's a certainty that the company will suffer. Clients will start to see a lack of quality, timeliness and customer service. In a world of client-related satisfaction, this is a recipe for failure. Negativity in the workplace needs to be recognized and resolved by both employees and management. Employees need to know that negatives are addressed and then be encouraged to MOVE ON. Management needs to acknowledge negatives yet respond with openness by maintaining the communication lines and tools needed to reach a solution. Tools include meetings, seminars and counseling. One excellent source is the American Management Association: http://www.amanet.org/. Susan Combs, Project Office Manager, Documentation Strategies, Inc.
Tuesday, November 13, 2007
Two Negatives Do Not Equal Workplace Positives
What does Project Management have to do with Software Development?
The development style of a software project has a huge impact on the way that the project is managed. Until now I have been a strict believer in Iteration, while Jeff is a die-hard Waterfall guy. Over the last few weeks I have had the opportunity to sit in on Jeff's Project Management class. Any project needs to be managed to increase its likelihood of success. However different development methods call for dramatically different ways to manage the project. Since I co-teach a project-based course for software developers at RPI, this simple fact is going to change the way we present development strategies to our students. I have a large collection of software development, UML, and other related technology books. Jeff grabbed Effective Software Project Management by Robert J. Wysocki from the shelf and refers to it in the class. I started reading it to get more information about a segment of the class I am contributing to. Wysocki talks in great detail about the different development models. He makes it quite clear that each development model has its place in the world. Iterative development is very good for projects where the solution is not fully crystallized in the minds of the stakeholders and the developers. Waterfall methods of development are suited for projects where the goals and solutions are completely developed and are not likely to change. In our class at RPI, we poo-poo Waterfall methods as being risky as there is no feedback from the customer and testing. Using a waterfall methodiology an extended period of time can go by before the software being developed undergoes any kind of assessment for viability. When the developed software is evaluated, it may or may not do what it is supposed to do. If it fails its tests, lots of effort and resources, already spent, could be wasted. Using iterative development methods, you can have those results much sooner and that potential loss can be minimized. Jeff argues that iterative methods are repetitive and wasteful of effort. The customer must have much more involvement in the development cycle and could potentially hold up the works if they don't respond in a timely fashion. (Experience shows that this is more common than we would like to think.) If a customer is not diligent about their response and their inspection the same result is easily possible. Near the end of the development cycle the customer could decide that the project is not really going in the direction they wanted and didn't realize this until now (because they hadn't been paying close enough attention). In an email I received from Wysocki he told me that his book is the first step in developing a new discipline that combines software development life cycle and project management life cycle. Stay tuned for more developments about this emerging technology that could change the way we do things into the future. John Sturman, Senior Consultant Documentation Strategies, Inc.
Monday, October 29, 2007
The future is here and it’s spelled DITA
If you are considering moving to an XML implementation of your content, DITA is the way to go whether or not you're using a Content Management System. When I first started playing with structured content, I had a dilemma as to whether to move toward DITA or DocBook. DITA is proving to be the winner of this contest. DITA is not just a DTD or XML schema in which to provide information; it is a true architecture that allows for unlimited extensibility. That said, extending a DITA implementation is not that simple, but to a seasoned XML jockey, not hard at all. It requires creating some new XML that inherits from a piece of the existing DTD. Once the extension is created properly, it fits right into the architecture and should work with the existing tools. Both DITA and DocBook have wide adoption and lots of already developed tools and processes. DITA is quickly being adopted by more and more mainstream applications. The most prominent evidence of this is Adobe Framemaker. Framemaker has become a real XML WYSIWYG editor, allowing users to edit DITA topics without having to convert back and forth between file formats. The latest version wraps a full DITA implementation, allowing users to develop DITA topics and maps using a familiar and powerful interface. Other applications which have adopted DITA include XMetal, Arbortext Author, and several Content Management Systems, like SiberLogic, and Vasont, and Astoria. John Sturman, Senior Consultant Documentation Strategies, Inc.
Friday, October 26, 2007
Hello? Is Anybody Listening?
Communications happens on a consistent basis throughout much of our waking hours. For as 'natural' as communicating can be, why is it that in when communicating should be happening the most, we seem to stall in the middle of the road? Especially in the world of business, every type of communication has an outcome within the work environment. Whether it is done as part of the normal work day or is enveloped into a small to large project, poor communications can impact the success of a project, as well as the parties involved. Proper, solid communication is the foundation of any good business. How a company communicates with other companies, customers and their staff will have a direct impact on the successes or failures. In today's world of information technology, pretty much any type of communication can be used and re-used in a variety of ways. A few different ways of purporting good business communication are: Today, many businesses use the Internet for communicating. Even though electronic communications is considered state-of-the-art communication, it can also be a challenge to make it work positively and effectively because of the lack of body language in the communication. The receiver of the communication can only make interpretations based on the words alone. On the other hand, when written with professionalism, expertise and proper business etiquette, it can be a very successful tool. Not all communication is written so don't forget body language! Body language works like a 2-way street. Your body language in conveying your information will weigh heavily on the listeners' approval or disapproval of what you are trying to accomplish. In the same respect, watch your audience as your speak. Are they alert and responsive to what you are saying? Are they yawning and rolling their eyes, playing with their pen or drawing pictures on a piece of paper? Remember to pay attention to yourself as well as your audience. Business communication will only be as good as Management allows it to be. This can only be done by leading by example. Management needs to provide the communications plan, provide the tools, educate all parties involved and keep in mind that good communication will be only as good as the investment that is made into it on a continuous basis. Susan Combs, Project Office Manager, Documentation Strategies
A Content Management System is only as good as the organization implementing it
I recently attended the DocTrain East conference. Writers, managers, localizers, and vendors converged on Lowell, MA for this four day event. At DocTrain, people from all parts of the tech writing world come together to discuss and learn about technologies and methods relevant to their industry. One of the most important lessons I learned is that people play a greater role in a successful Content Management System project than the technology used. "What Content Management System should we adopt?" is a regular question that many documentation organizations ask. This is a simple question with no simple answer. There are many Content Management System vendors, but more importantly, every organization has different needs and ways of working. It quickly becomes clear that choosing a vendor should be one of the last decisions made in the long process of adopting a system. As one of the presenters said, "it's not a how-to but a who-to". In other words, it's not what system you're using but who is using the system. You can have the best Content Management System but if people are resistant to the process you'll end with up with disaster. At the same time you can give a mediocre system to a dedicated group of people and be very successful. John Sturman, Senior Consultant, Documentation Strategies
Monday, September 10, 2007
Relationships - the key to successful selling
I started my career selling Dot matrix printers to businesses around a small town in South India, where I grew up. Selling wasn’t easy then and doesn’t seem any easier now. To succeed in selling you need a killer product or brand or both. Without a sustainable competitive niche there are rarely any distinguishing factors either with products or services. If there is a distinguishing factor it gets thinner and thinner every day.
Given this seemingly bleak outlook, I believe one of the many ways to succeed in selling is the relationships one has built over the years. Here are few tips to develop and maintain relationships:
Maintain a Rolodex and go over it at least once a year
Re-establish contacts you’ve had in the past
Participate in local networking events
Invite to lunch people you want to do business with
Finally, identify client needs and follow up quickly to win their business. Whether you manufacture a product, develop software applications or provide a service, do your due diligence first and then follow up on a regular basis.
Happy selling!
Tuesday, September 4, 2007
Projects are like Plutonium: compress them too much and they blow up
Today’s Dilbert cartoon makes fun of project compression. The pointy-haired boss has a 300 man-day project and has just hired 300 people to complete it in one day. He’s telling them they will be fired tomorrow after the project is done.
Aside from the comment on modern high-tech employment (hire and fire, over and over), this strip reminded me of a famous quote from The Mythical Man Month, Fred Brooks’ tongue-in-cheek analysis of the fallacies of project compression. In the book, Brooks made the point that nine women cannot make a baby in one month, no matter how well managed they are.
As a long-time project manager, I am forever reminding clients of the 9-month rule. Every time you add a body, you geometrically increase interfaces. These interfaces (speaking, listening, reading, writing, and most of all, understanding) are human and by definition imperfect. At some point, and usually pretty early in the process, compressing a project timeline by adding bodies increases confusion and often makes things worse.
Good project managers spend a lot of time managing expectations. When establishing timelines and resource loading, don’t forget to plan for the inevitable requests for project compression. Determine what tasks can be parallelized, find places (usually back-end reporting) where extra bodies won’t gum up the works, and always, always manage user expectations politely but firmly.
--- Jeff Klein, COO, Documentation Strategies Inc.