Best Practices in IT

Learn, Practice, Improve

Most of my IT career has been as a consultant and a manger of consultants. Over the years I have established some patterns to follow that I find helpful in making projects and technology easier in the long run. I sometimes share these in mentoring sessions and have heard often enough “you should write that down” where I started to.

I am still writing these concepts down, and while they originate from a consulting perspective they translate to every day practices beyond consulting.

At the time of this writing (not reflected by the pub date), I am re-vamping this site. Part of the update is moving this content from a standard page to a category page. The navigation will change to reflect that when it is either complete or well along.

One way to keep documentation fresh

Scott S NelsonLeave a comment

Documentation should always have some built-in capability to receive comments and the comments should generate alerts to the content owners.

This process can vary greatly. In some contexts, readers can be allowed to edit the content. Or only some users. Those edits should still trigger alerts to the content owners for review.

Documentation often becomes stale because there is no easy way to communicate changes. Capturing improvements or updates at the time the document is used is the next best thing from when the content needs revision because what it describes has changed.

Bonus approach

For software documentation (especially for enterprise applications), if you use any kind of ticketing or kanban-style stories, include “Create/Revise Documentation” as a standard part of the Acceptance Criteria in your template.

If you found this interesting, please share.

© Scott S. Nelson
Path with cloudy destination

You can always get there from here

Scott S NelsonLeave a comment
There are many quotes to the effect that perfection is a path and not a location (my wording in this case).  To me, this is the essence of agile vs waterfall (and, to a degree, SAFe).
Agile trusts that high performing teams, following processes that support continual re-evaluation, will produce higher quality deployable results with the same amount of resources.
All methodologies have processes (or ceremonies). Properly followed, they can all produce good results. Whether one methodology will produce better results than another is fairly moot, because it isn’t the methodology alone that influences the results. It is where the focus of the team is while following the methodology that makes the difference.
A team that is focusing on a date will almost always have to skip some steps to make that date.
A team this focused on the completed product is almost always  going to miss an import use case (very simple products excepted).
A team that is focused on absolute perfection of every task is going to miss business expectations.
A team that is focused on sticking to an iterative process and willing to course-correct their approach to improve the next iteration will always produce better deliverables.
Leadership is less about providing direction and more about communicating where the team should focus to be successful. The goal is to have a shared vision and foster the flow state that will support realizing some version of that vision at regular intervals.
Or, to use another similar quote, “This is the way”.
If you found this interesting, please share.

© Scott S. Nelson

Phooey on Part-time Proposal Primary

Scott S NelsonLeave a comment

There should be at least one person involved with any given proposal that has no other task than working on the proposal. This person does not need to be the most senior on the proposal team or even the “owner”. The key role of this dedicated resource is to track all contributions and ensure that the final proposal has a single voice and standard format (even if the actual work of making that happen is delegated). This goes double if the proposal is for a public RFP.

If you found this interesting, please share.

© Scott S. Nelson

Email Best Practices

Scott S NelsonLeave a comment

There should be books written on this topic. Many, and all with fewer than four paragraphs or no one will finish them.

Manage email subjects

Whenever someone is compelled to label something as “common sense”, everyone agrees even though it is clear that it is not all that common because it had to be called out. That can apply to just about anything I have to say about email. So here are a few common sense concepts about email:

Keep the email to a single topic

While some people are good at making context shifts in a conversation, there are many people who find switching topics difficult. In verbal communication a missed context switch will often result in a response being framed in the previous context. The same can happen in emails, or (worse) the new context is simply ignored. Why is it worse when ignored? Because when a subsequent email requests a response to the ignored/skipped topic, the recipient will either again miss it or reply that they have already responded. This is neither obstinance nor resistance; it  is how their brain perceives it. Keeping to a single topic may initially seem inefficient (and it is if you know for a fact the recipient is good at context management) yet it is far more efficient to write three emails and get a congruent response to each than to write one email followed by a chain of a dozen follow ups that may or may not conclude in everything being answered.

I feel so strongly about this, I wrote a longer rant recommending to Keep Emails to a Single Topic a year ago.

When the thread changes topic, change the subject.

Even congruent email chains can move from one topic to another. If you are the one writing the email with a topic change, change the subject in the email, even if you do retain the earlier thread as a related reference. If someone else changes the topic, update the subject in your reply with [New Subject] (was re:[Old Subject]. When you go to search your email for a thread several weeks later, you will be glad you did.

Trim to fit

When replying to an email where many people are on the thread, remove the list of recipients from the original email, especially when updates are inline (another bad practice).

Many more tips to come…

If you found this interesting, please share.

© Scott S. Nelson
Project Team

If it could have been an email, skip this post

Scott S NelsonLeave a comment

Some tips from a previous page on this blog about meetings…

Two Types of Meetings

One type of meeting is for the purpose of people with something in common (a project, a department, a role, a skill set, an interest, etc.) to gather and have a free form exchange of ideas. These types of meetings need only a clear topic and basic shared ground rules (at a minimum, always be respectful) to be productive.

The other type is to accomplish one or more specific goals. If there are more than three goals, some will be missed (and some can still be missed with only three). These types of meetings require a specific agenda beyond the meeting topic. They require that someone is recognized by all as the leader or facilitator or moderator and that person knows how to perform in that role. They require someone good at note taking to be the scribe (or a method of recording the meeting on a shareable medium).  If the meeting is missing any of things, any successful outcomes are the result of luck or the meeting was really one of the first type.

Record All Web Conferences

It is a good habit to record the web conferences you host and request other hosts to record and post the recordings for participants. This allows you to focus more on the meeting rather than taking notes. It also provides a reliable source of reference when different attendees later have varying recollections of statements and decisions made in meetings.

Prepare to Participate in Project Retrospectives

The project retrospective is a chance to commit the lessons learned to memory. The issues with retrospectives come in bookend-form: It takes a long time to get the creativity and honesty flowing at the start of the retrospective and the captured lessons are rarely referenced by anyone not in  the meeting. For the latter, you can blog about the lessons you’ve learned and for the former you can come prepared (you’d be surprised how often you are the only one).

To be prepared, it is best to keep running notes throughout the project (I use Evernote) or at least to put together some thoughts at least a day in advance of the meeting. If you are the only person that does this you can single-handedly knock over that first bookend (just like that couple that would always be the first to dance in school).

I strongly suggest that you have as many positive items available as possible so that you are ready to start it off on a good note.  If you have several, space them out if others do not

Another approach that I have found to be successful may seem counter-intuitive: Make your first “area for improvement” shared something that you were responsible for. This is especially important if you are the first to provide it because by honestly recognizing and sharing your own contribution to things that went wrong it will ease the concern others have of being picked on. The group will be more relaxed and open up sooner, making the meeting highly productive.

If you found this interesting, please share.

© Scott S. Nelson