Presentation

I made a video that was my actual presentation including going over all of the slides and analysis on the usability test. The presentation runs slightly over 50 minutes. You can also download the slides from the talk as well.

Usability Test

If you want to watch and think through the usability test in its entirety without my commentary you can view it through the UserTesting.com site.

View Usability Test

Resources Mentioned in Presentation

Here are links to the various sites and applications I mention in the slides.

• Morae
• Sliverback
• UserTesting.com
• Open Hallway
• Optimal Workshop

The Mythical End User (Who Really Is You)

We all know (at least I hope we all know) that designing by committee is a shortcut to failed design (this video nails the comedy behind it). One of the first mistakes made in design meetings and teams is that our own personal preferences and desires get projected onto a mythical end-user. How often have you heard something like this.

• “Our users don’t like drop downs.”
• “I don’t think our users will want to see green there.”
• “You know, I’m not sure end users will like that.”

When we probe more we find out that these end-user projections are just personal preferences. The problem of going into a client and suggestion you’re focused on “the end-user” will almost instantly and unconsciously turn our design discussions into projections of this mythical end-user. The well versed usability expert Steve Krug puts it in perspective.

“And the worst thing about the myth of the Average User is that it reinforces the idea that good Web design is largely a matter of figuring out what people like. […] The problem is that there are no simple ‘right’ answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested.“
Steve Krug, Don’t Make Me Think: A Common Sense Approach to Web Usability (pg. 128)

The Misuse of End User Research

It’s not without debate that understanding what types of users that will use your application is of value. If your application has a very specific focus and niche group it makes a lot of design decisions a lot easier. However, often times a mistake made is when we start placing all types of value on suggestions and feedback we receive from users.

Don’t jump ahead on me. I’m not stating that users don’t have valuable input at many stages of the design and maintenance process. If I believed that I would also tell you that usability testing is the largest waste of time in a project which I clearly do not. But I believe that decisions made by an informed UX researcher are often negated, because end users make proclamations about how they feel an application should behave. This ultimately makes your application less worthwhile to larger groups of people. Don Norman states the following.

“Sometimes what is needed is a design dictator who says, ‘Ignore what users say: I know what’s best for them. […] The ‘listen to your users’ produces incoherent designs. The ‘ignore your users’ can produce horror stories, unless the person in charge has a clear vision for the product, what I have called the ‘Conceptual Model.’ The person in charge must follow that vision and not be afraid to ignore findings. Yes, listen to customers, but don’t always do what they say.”

When designing an application a user’s opinion should be stated and noted but not used as the barometer for our design activities. Let’s face it, if we’ve done any work designing application the one thing that that will show up time and time again is that end users don’t know what they want. It’s not their fault either they are simply caught in the middle. Successful applications help users through accomplishing what they need to do without an unfair focus on what they think they want to do.

The Better Emphasis: Designing for Activities

In the article mentioned above by Don Norman he goes on to explain more of why designing for activities is better than user-centered (he uses “human-centered” terminology). All applications exist for a reason, and that reason is to help someone accomplish a task or achieve a goal. It doesn’t matter whether the activity is buying clothes, researching movie times or playing games online. If designers were more honest with themselves and spent less time laboring in Photoshop they’d realize that better time is spent thinking about design in terms of what goals and activities need to be accomplished by your users.

It is this focus that really helped me see a new light in designing user experiences. When I was liberated to think more about designing applications that accomplished goals and less about whether they application used Verdana or Arial I became much more effective. All of the sudden the applications I worked on delivered more utility and saw users returning more often. It is the reason I implore designers everywhere to not use “user-centered design” but instead turn your clients attention to “activity/goal-centered design.”

Conclusion

The astute reader will notice nothing I’ve said here goes against the classically defined tenants of user-centered design, but I wanted to illustrate why using that language with less educated clients doesn’t ultimately help you in your design activities. Be intentional and careful with the words you use, and I guarantee you will find more success in your projects.

Political Barriers

Politics are often the first road block encountered when bringing a tool like SharePoint into the enterprise. Someone becomes sold on the platform usually in IT but sold to executives shortly afterward, and then the backlash begins. The first to bring argument against the technology are those who monitor and/or administer legacy systems. The BroadVision/Notes/etc team are not keen on having “their” application moved into a new platform and potentially turned off. SharePoint becomes the hardest to sell to these individuals. Instead of jumping on the new technology train they fear the loss of their job and will fight it to the end.

Cultural Barriers

Usually an enterprise class technology will make it pass the political barriers, because some executive (should have) been sold on it and pushes it through. The next group of people who become change averse are the end user or information worker as Microsoft calls them. These are the people that are being told that the file share is not the way to store and collaborate anymore. Often times frustration ensues, and many people don’t care to see how much better SharePoint can potentially do their processes and fight it.

This is a stage where “quick wins” are important. During this phase the SharePoint implementation team take an existing process that was cumbersome and error prone and do something like automate it with workflow. They could also make the Sarbanes-Oxley compliance team by showing auditing. Here you try and bite off a little bit, show improvement, and these people who benefit become evangelists for the product. The most effective sales person inside of a company is another co-worker.

Technological Barriers

The technology itself can become a barrier if it is not planned wisely. Let’s say you being to roll out the technology, and it’s painfully slow because you have SQL issues. The resulting effect could turn many potential users into quick haters. They then respond that “it’s too slow to use” and it becomes a hard stigma to overcome. It is important that the technological implementation is thoroughly assessed and implemented before training and implementation begins, because when the implementation starts it’s very important to set a precedent of reliability.

There is another technological barrier that is actually more cultural but very related. There will be people who instantly grab onto the technology and want it to do everything for them. These projects often can creep into an implementation and push a project off its timeline and sideline its overall implementation and adoption. It’s very important to have a project plan that is detailed in scope and people involved that want to see it saw through. Getting other ideas to use SharePoint is great, but not when it slows down an entire project.

They approach IT solutions without a preference towards one technological solution or another, or become that way when cornered. Often this type of “agnostic solution” references to disciplines such as taxonomy development, governance, etc.

“Agnostic” Technological Solutions

Some companies attempt to say they can do any kind of technological implementation that the client desires. This is a more dangerous than saying they are completely bound by a technological solution (i.e. I can only use technology x). It is very misleading to make a client think that they have a methodology that is supra-technological solution.

While it’s true that enterprise information architecture is a discipline that can be applied to different technologies it does take on a very different form based on the solution the client needs. For a consultant to go in for analysis pushing one technology and when the client desires another it’s irresponsible and misleading to inform them that they can go forward with the implementation. A failed project is only down the road. The paradigms of application with a field such as EIA varies much on the technology. How one does taxonomy design and implementation and SharePoint another product is very different and should not be taken lightly.

While this is a rant of mine it is something I feel a client should be made aware of a consultant that goes down such a dangerous road.

Because we often don’t fit well into a nice category we are responsible for a much larger part of designing information systems. Nothing makes this more evident than the process of creating wireframes, and I’m going to address the debate on interactive vs. static wireframes in the context of our role in the development process from the perspective of designers, customers, and managers. The time has come to more clearly define who we are, the role we play in the development process, and be sure that we satisfy all interested parties in the process.

The following quote from Rosenfeld and Morville in their IA magnum opus will be expounded upon:

Wireframes represent a degree of look and feel, and straddle the realms of visual design and interaction design. Wireframes (and page design in general) represent a frontier area where many web design-related disciplines come together and frequently clash. The fact that wireframes are produced by an information architect (i.e., a non-designer) and that they make statements about visual design (despite being quite ugly) often makes graphic designers and other visually oriented people very uncomfortable. For this reason, we suggest that wireframes come with a prominent disclaimer that they are not replacements for “real visual design.” The fonts, colors (or lack thereof), use of whitespace, and other visual characteristics of your wireframes are there only to illustrate how the site’s information architecture will impact and interact with a particular page. Make it clear that you expect to collaborate with a graphic designer to improve the aesthetic nature of the overall site, or with an interaction designer to improve the functionality of the page’s widgets. (pgs. 308–9)

Are We Interaction Designers?

The answer is yes and no. We certainly have a role in the overall user experience process, but we are not responsible for how a user actually interacts with an information system. Let’s face it our annotations don’t replace the role of a qualified interaction designer. I will be focusing on the fact that our value-added proposition is that we can effectively lubricate the evolution from a stiff business requirements document into something reminiscent of a usable system that is then passed onto the programmers, designers, and usability gurus.

Please understand that I understand that the field of IA, UX, and all other aspects of architecting interfaces often happens with just a single person. I don’t want to minimize that as I myself served all these hats. I’m simply pointing the role of a wireframe in the overall interface design life cycle.

There are an abundance of tools that purport to aid architects in creating interactive wireframes, but then what does that display to our team members? Does a designer want to be handed a garbled, poorly-coded, auto-generated layout with cookie-cutter interactions? I know when I was a designer I wanted at least some liberty in what the interaction and user experience ended up looking like. It’s true that in most design shops that the designer serves an IA role, but when we have dedicated information architects shouldn’t we stick to doing what we do best? Don’t we deliver more value in designing taxonomies, labels, navigation, and conceptual layouts?

The Customer’s Perspective

The customer will always prefer something interactive—that isn’t a question. Looking at a bland Visio document doesn’t exactly inspire someone, but what is the purpose of the wireframe? Are we not trying to get the customer to focus on the layout, labels, etc and not how the interaction will take place? When we design interactive wireframes doesn’t it also pigeon-hole the designers to design around the interactions from the IA’s wireframe?

Here is what usually happens when you give anything interactive to a customer when you’re trying to do IA and not interaction design/user experience. They will spend more time clicking around complaining about the pop-up windows and the way it looks and not what we actually want them to be looking at? The value in static, seemingly dry wireframes is that they have no choice but to focus on what we bring to the table in terms of IA and not user experience.

The Designer’s Perspective

Designers are artists in their trade. They make money, because they know typography, colors, interactions, and all the other unique challenges to being a designer. I can’t tell you how many times I’ve asked for wireframes when what I was given was a poor mockup. Let us answer once-for-all that a mockup and wireframe are not the same thing. The designer does not want to be given a mockup—that is the very thing they are experts in. The problem only escalates when an information architect tries to tread too much on what the designers are supposed to do.

When an information architect goes out and converses with the customer, interacts with the functional business requirements, and creates and receives buy off on a wireframe that it is almost invaluable to a designer and the other programmers. A programmer can then focus on database schemas, object orientation, while the designer can worry about the aesthetics of the interface. You will become a programmer/designer’s best friend if you can abstract the job of creating labels while not dictating how the interaction and how it will actually look.

The Project Manager’s Perspective

Project Manager’s are often the hardest to sell on the value of IA. They look at IA as something the designer does, and that only contributes to the difficulty of selling the importance of our field. They are likely to look at the designer and say: give me a mockup to send to the customer, and when money becomes an issue in the project they’ll cut IA’s always before designers. I have never heard of a designer being cut in place of an IA. It has never happened.

We need to carve out what we do best. Designing information systems amongst different skill sets is not reminiscent of some measure of unrelated diversification—everything we do as IA’s is related to everything else. We just need to be sure that what we do we do as well as we possibly can while enabling our fellow designers and programmers while appeasing our customer.

Conclusion

The thesis of this essay was to define what our role is in the wider scope of the development process, and address just one small part of our value added proposition in the development of wireframes. We have so much to offer, but we must be careful on where we tread because we fill such a political position in the development process.

In Essential SharePoint 2007* the authors lay out the “four C’s” of company portals that MOSS can satisfy. These can be used as a good starting point to sell them and bring MOSS into your organization.

Communication is a fantastic reason to bring MOSS into your organization’s processes. Many companies are plagued with disseminating important information both to internal and external individuals, and MOSS can aid in delivering timely, relevant, and accurate information to your target audience. Through the use of MOSS sites geared for news, announcement web parts, blogs, and audience targeting—MOSS can greatly help your organization accomplish this much-needed functionality.

Collaboration is the strong point of MOSS and also the easiest to sell. Your organization struggles from discerning which document is the most recent, and people in your organization realize that e-mailing around a document is not an effective way to collaborate. Here is a great time to talk about the workflow capabilities in MOSS. Demonstrate an approval workflow which engages the management instantly by showing them how the whole process can be automated, contained in one area, and management can see what’s holding up the workflow. Add onto this team sites with robust document management capability with an extensible security model, and you’re well on your way to convincing them.

Consolidation is probably the reason you were tasked to find a better solution than file shares. There is no way anymore to know where to get what and if it’s even accurate. With enterprise search you can ensure that your users can always find the document (with a good metadata structure/information architecture). You can also sell the Business Data Catalog (BDC) which can crawl those old file shares and bring them into the same search interface. You’ll also see eyebrows rise when you show them the business intelligence capabilities in MOSS such as Key Performance Indicators (KPIs) which will help your management make the best decision on the most up-to-date information.

Consistency is something that we all long for in our IT applications. Right now your public facing website, other marketing materials, and even standard company documentation can’t look the same for any length of time. With the use of master pages you can be sure that the interface changes you make will be reflected across your entire MOSS installation. Having problems keeping that PowerPoint template up to date? Creating a content type will ensure that your users will always have the latest version of the companies template.

These are four great selling points of MOSS to bring your management on board. When partnered with some simple demonstrations that will create a strong case for MOSS.

*Jamison, S., Cardarelli, M., & Hanley, S. (2007). Essential Sharepoint 2007. Reading: Addison-Wesley Professional.

This was impossible until recently when Harvest published their full API. I now have the ability, through REST, to retrieve my data via XML, parse it, and put it where I choose. This lead me to creating a WordPress plugin to accomplish this, and I was encouraged by someone at Harvest to make it public domain. So I present to you the “Harvest Reports WordPress Plugin.” See the screenshot on the right for what will be accomplished with the plugin.

Remember that this was made to solve a specific business need, namely the display of pending costs incurred since the last invoice. This is not meant to be an exhaustive representation of their API as it only uses a slice of it.

Requirements

1. WordPress 2.3+
2. A Harvest Account
3. PHP5

You might wonder why you need PHP5 as WordPress only needs PHP4. I use the PHP5 SimpleXML functionality to parse the XML. This is far easier then trying to do it in PHP4. Most hosts do offer PHP5, but you might have to add the following to your .htaccess file to utilize that edition.

AddHandler application/x-httpd-php5 .php

Installation

1. Download the plugin
2. In WordPress 2.3 — 2.5 go to “Options” — “Harvest Reports”, and in 2.5 go to “Settings” — “Harvest Reports”.
3. Enter your information
4. Hit “Save”
5. Go to “Manage” — “Your Chosen Title” to see the report

To get your project ID go to your Harvest dashboard — “Manage”, and you’ll see your projects listed. When you open up one you’ll see a numerical value in the URL bar (e.g. yourname.harvestapp.com /projects/49691/). The value you want is 49691. Remember this is only meant for one project, as that was the business need I needed it to solve. Also, if you want to limit the end date on the report I have included that, but leave it blank to retrieve data up to the second.

Caveat On Hourly Rates

Since this plugin is intended to ultimately provide a monetary figure I wanted it to get the default hourly rate from the API. Unfortunately, when I first parsed the XML I saw that despite the fact that my tasks use my default hourly rate nothing was in the XML returned. I pinged their support and got the following rationale.

“When you read the Task API, you basically get back “No setting” at the second (task) level. We use the rates for reporting (and invoicing coming soon), here the defaults get cascaded. But for the API no cascading takes place to make it evident from where the value comes.”

What this means is that for every task that is used for the project you have to go in and manually set the hourly rate. Not ideal, and to me it’s not expected behavior (especially since the reporting tool inside the Harvest interface automatically uses that value), but once you set it you can forget it.

Upcoming Features

Even though I’ve worked a lot on this and need a break I still have improvements in mind.

• JavaScript date picker
• Exception handling from the API
• Ajax retrieval of projects inside the options page (no need to insert a project ID manually)

I also need to double check that is handles tasks that aren’t billable by default correctly. Since I only track tasks that are billable I didn’t test this, but maybe someone can verify for me.

Props

I want to say thanks to Danny Wen of Harvest for encouraging me to do this, and Andrew Charlton of Geekly Weekly for pointing me in the way of cURL and SimpleXML.

The Old, Work-Down Approach

Most of us are very familiar with this approach. We meet with the prospective client, define requirements as much as possible, and approach the development task as marking off completed requirements until completion. This methodology works fine when you have no scope creep, have low risk, and well-defined requirements; but unfortunately this doesn’t describe most of our projects. This is especially true for us that freelance as the risks involved for us are much higher.

A project manager typically has three variables to use in the work-down approach: time, resources, and functionality. What has happened is that a fourth area needs to be recognized-namely, quality. Due to this and the truth that most of our project managers don’t take quality into account as one, if not the, most important attributes of successful software development from the very beginning.

The Value-Up Approach

When approaching this paradigm we need to remember what most satisfies us when we make a purchase. Even though we might not consciously think of it, when we make a purchase we are intending the purchase to return value to us in one form or another. I am most satisfied and suffer less cognitive dissonance when I see the value received from my purchase.

In the never-ending process to ensure that our customers are satisfied we should view their investment in us as a desire to receive value of some kind. Concentrating on a consistent flow of value to the customer should be a paradigm that will utilize, but we must not internalize as we must also convey that emphasis to our customer.

Software development is also different than other forms of development. For instance, when building a bridge there is no intrinsic value in a bridge that is only half-way done! But in opposition to this, software development isn’t build along the same vein. My customer can receive benefit by starting to use an application even though the interface is not yet completely finished. The earlier our customers see value being delivered to them the happier they will be throughout the process. Even though I’m not endorsing an agile approach to software development, this approach, when combined with agile iterations can help you effectively deal with the inevitable scope creep.

Contrasting the Paradigms

The book lays out a table to visually see the impact of using the paradigms (of which I will use the majority of the table), and the information is verbatim from the book (pgs. 6–7). While not exhaustive, it will help us to see tangible results of making such a change.

The first thing to realize is that in a value-up paradigm we embrace that changes happens throughout the software development process. I’m sure we have all had our fair share of frustration when we complete tasks according to the original specifications, but when we from the beginning perceive change throughout the process as inevitable-and ultimately positive-then it makes the process much easier for us.

Notice as well that the only true values of progress measurements are items that actually give value to the customer. In other words, our Gantt Chart should reflect tasks that actually give value to the customer not only tasks completed. In the context of a web application, that might be the installation and/or customization of a content management system, maybe it might be the ability for the user to customize the interface, or it could be a litany of other items. The only thing our customer should hear from us is that we are delivering value and utility to them throughout the process. This also helps when our customer comes to us and says something like: “This doesn’t do what the requirements outlined.” Well, in our perception it might be what the requirement stated, but if value is not given to our customer then we haven’t made any progress.

I do understand that there is variance that, no matter how much you try and avoid, conflict happens over what requirements. But the adage, “the customer is always right” is still very applicable to software development.

Moving from the Ethereal to the Practical

Now that we have outlined the philosophy we must ask how this can be of practical value to us in our everyday work. The best way to bring this back down to earth is to share a practical example.

I get to do software development with government agencies (Air Force, USAID), and if any of the readers share that experience then they understand my pain and frustration. More than any other clients, government agencies are some of the hardest to work with. The paradigm for development in general, whether software or weapons development, is the traditional (non-agile) methodology of outlining all the requirements from the beginning down to the type of paper you’ll submit to them.

These government agencies are familiar with only seeing something when the developer feels it’s presentable, and updates are traditionally provided in terms of a work down paradigm. I had to, with some very conscious thought, change the way I conversed with my customer. Here are some examples of changes I made in conversing with my customer. The first list will be the traditional way of conveying progress, and the second list will be the verbiage I changed from a value-up paradigm.

Work-Down Terminology

• Per the requirements documentation, we have completed 1.A, 1.B, and 2.A.
• Your new requirements are not in the original document so we will have to stop and revisit the documentation.
• We have successfully completed the project according to the requirements.

Value-Up Terminology

• With the completion of this iteration, you can now dynamically edit your content, customize the layout, and you can start to see how it will function as we finalize the user interface.
• New requirements are a natural part of the process, and we will focus on your new requirements in the next iteration.
• We have successfully completed the project in light of your desired capability.

Conclusion

The value-up paradigm is a powerful way to approach software development, but change is something that needs conscious focus. The value of changing paradigms will become evident nearly instantaneously as the relationship improves between you and your customer, and the reputation of your company as one that delivers tangible value early grows and supplies a constant flow of work.

You can view the slides for my original presentation on SlideShare.

I came to realize the value of specializing in one field. For instance, it would be counter-productive to mandate a DBA to learn Photoshop inside and out, and likewise it would be counter-productive to have the UI person learn how to know how to write every variation of database indexes. But I also saw the lack of knowledge that each had even of what the other team member’s responsibilities were that led to inefficient meetings, miscommunication between clients (especially in terms of requirements gathering), and overall it lead to a “that’s not my job” mentality that hurt the overall productivity of the team.

The Thesis

I believe we need address the lack of communication between the team members by increasing collaboration and at least a general knowledge of what the other is doing. If the programmer knows that the UI person is very concerned with Web standards then they can address that while he designs (among many other examples). All members of the team address the same client with the same requirements, and with knowledge of the various aspects of the SDLC the client can receive the maximum amount of value for their investment.

The article is broken up into examining the role and duties of the project manager and the developers. Both have unique responsibilities in order to ensure that the efficiency of the team is what it can be.

The Responsibility of the Project Manager

The responsibility of making this work falls on all members of the team, but the project manager (project lead, technical lead, etc.) is the one that has the authority to delegate who will work with who and for how long. There should also be a strong impetus for this person to embrace this ideology, because when conflicts arise between developers or between developers and clients the project manager is the one usually responsible for resolving the conflict.

By delegating developers to have a working knowledge of what the other members are doing through the software development and maintenance cycle then all members are able to offer constructive criticism to one another and help in a time of need. It is a great asset in the toolbox of delivering quality software.

Reduce Developer “Possession” of Code
I was sitting in a meeting, and when a customer bug request came up in a certain module then we automatically pointed to that one person who designed the module. The mentality behind it keeps other people on the team from double-checking the code and able to help each other of bug fixing and future development. Kent Beck, the popular proponent of eXtreme Programming (XP) (which I neither endorse nor discourage) says the following on “collective ownership.”

“One of the effects of collective ownership is that complex code does not live very long. Because everyone is used to looking all over the system, such code will be found sooner rather than later. And when it is found, someone will try and simplify it. […] Collective ownership also tends to spread knowledge of the system around the team.” (Kent Beck. Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series). New York: Addison-Wesley Professional, 2004.)

Regardless of whether one uses XP or another SDLC, the concepts introduced are a good starting point to increase the amount of communication between team members, increase productivity, reduce errors, and deliver higher levels of customer satisfaction.

Facilitate Team Briefings
We all love to talk about what we’re passionate about; so why not use that to the advantage of your team? I work on a team where the project lead encouraged us to give a briefing on a new technology or certain aspect of their job that would benefit other members of our team. Let’s use an example.

The user interface designer is constantly frustrated why the DBA and developers just don’t “get” web standards. It leads to conflict, because the developer is solely concerned about the function and not the form (in an extreme example). Well, why not let that designer brief the team on the value of web standards? It would also be helpful for that individual to outline best practices so the application has both maximum form and function. Often miscommunication happens over very small issues, and by taking the time to clearly outline a concept then the problem often goes away.

In fact, recently I gave a briefing to my development team introducing CSS and CSS best practices. Months of frustration on my part was alleviated as many members of the team started to see the business value of separating presentation from structure. We are now converting our old table layout to a CSS-driven layout.

Managing Many Egos
Let’s face it-designers and programmers have egos, and not just small egos but large egos. Everyone has their own philosophy on how development should be done; this is normally a good thing that brings variety and many perspectives, but sometimes it can also be a hindrance when trying to empathetically communicate with team members.

How many technical meetings have we all been in that seemed to go on and on and seemingly accomplish nothing? It seems like we spend most of the time debating philosophically on the best route which is perpetuated by our own individual ideologies. This can, and should be, alleviated by realizing that what’s best for the application isn’t always how we feel it should be.

The project manager has the added responsibility of ensuring that these debates don’t get out of hand by effectively managing the conversation and ensuring that every side is heard. Ultimately, every business decision that is made must be made by some superior who weighs the options and chooses the best. A manager that is open yet firm in making decision does wonders for moving development along.

The Role of the Developers

The project manager can do quite a bit to ensure to ensure that the team works in an optimized state, but ultimately it comes to the people that comprise the team-the developers. I want to give a few suggestions for the developers to ensure that cohesiveness is improved.

Everyone Should Test Everything
A great way to get team members to get involved with the entire project is to not relegate testing to individual projects or a singular tester. By involving all members of the team in testing helps ensure that the quality of the application will continue to increase. I am continually amazed at how members of my development team don’t even know how to use many aspects of the very application they develop. It is often the result of the “possession” of code problem address above.

Improved Knowledge Management
A good development team should be the most experienced and concerned about knowledge management. As the application matures then it becomes more and more necessary to ensure that correct and complete documentation is retained (although don’t wait to start). The great knowledge management challenge of capturing tacit (un-written) knowledge is critical to address when you’re in a development team. As developers come and go the need to be less reliant on one or two developers is extremely important. You should, at least in theory, have enough documentation to move developers around and if necessary to replace.

Fostering Mutual Respect
Aretha Franklin had the idea when she said: “All I’m askin’ / Is for a little respect”. We all love to know that we are respected by our peers, but it only comes about when we extend it to others. That whole Golden Rule idea is very applicable in this situation. When developers create an atmosphere where we respect one another and each other’s contributions then more efficient communication is likely to take place.

In Summary

There are many ways to engage the entire development team, and the responsibility lies within the managers and the developers. It is truly a trial and error effort, but if you and your team seek to improve in the areas above then you are more likely to deliver a quality product to your customers and improve professional satisfaction.