Developing a data communications strategy

Robert Bogue August 30, 2005 No Comments

Any data communications proposal can look good on paper until you dissect it by evaluating its reliability, expandability, and complexity.

Whether your organization has two sites or two hundred sites, figuring out how to manage the data communications between those sites can be a real challenge. With a vast array of options, it’s often hard to determine what’s best for your organization. Here are three key evaluation criteria you can use to make the right decisions for your connectivity.

Reliability

In most cases the reliability of the network is a critical component to how useful it is. Even in organizations where the ability to communicate between sites isn’t core to the business because there are no central databases to be accessed and no real-time need to share information, loss of connectivity is still very disruptive.

Reliability is measured by the frequency, the duration, and the completeness of outages.

http://www.techrepublic.com/article/developing-a-data-communications-strategy/

Anatomy of a Software Development Role: Development Manager

Robert Bogue August 25, 2005 No Comments

It is possible to believe that there is nothing left to be done. That all of the roles outlined thus far is all that is needed to make the process work. However, the role of the development manager is critical to the long-term success of the software development team. The role that the development manager plays – particularly when interacting with the project manager – is essential to a continuously improving process. (If you’ve not been following the series, you might want to read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Development Manager role?

The development manager’s role can be described as “everything else”. Although accurate this description is not very illuminating.

The development management role is the role whose purpose it is to keep the vision on track. This is much like a CEO, who sets the vision for an organization. This of course differs from the COO, who-like a project manager-ensures the day-to-day operations. While it’s the project manager’s goal to get the project to the finish line, it is the Development Manager ‘s responsibility to look ahead to make sure that the finish line is the right finish line to be reaching. While the project management position is a management position, the development manager role is a leadership position. Click here to see how the the Deployment role fits within the full organizational chart.

Read more of the article at http://www.developer.com/java/ent/article.php/3529081

[Author’s Note: I really enjoyed the mental exercise that writing this series brought. It was a good way for me to clarify my thinking around the various roles in the software development process. I hope that it can provide a framework for understanding how people fit into the process in your organization. The next series is on Coding standards and starts in just a few weeks. I’m always happy to get input on what you think should or shouldn’t be in coding standards.]

Create a path to reach your strategy

Robert Bogue August 23, 2005 No Comments

If you’re having trouble getting your team to execute on its strategy then you may need to lay out the path in more detail than you already have. Here’s how.

Many organizations find developing a strategy a difficult and time consuming process, one that they’re so exhausted by they just hope that it will implement itself. If you’re having trouble getting your team to execute on its strategy then you may need to lay out the path in more detail than you already have. Here’s how.

Understanding strategy

In most organizations, strategy is just a rough idea of where the organization wants to go. It’s an ideal view devoid of the distractions that the real world brings. Understanding that a strategy isn’t real helps to illuminate the fact that there’s a gap between the current reality and the new vision.

Never was this as true as it was at the Fishburn Group. The Fishburn Group had been in the recycling industry for years but recognized the change that was sweeping the nation as technology began to be cycled through organizations at an ever increasing pace. They were becoming so overwhelmed with material that they couldn’t find a home for it.

http://www.techrepublic.com/article/create-a-path-to-reach-your-strategy/

Getting leadership and management in your organization

Robert Bogue August 16, 2005 No Comments

There’s a difference in the skills sets for leadership and those for management. Learn the difference and how to incorporate the best of both worlds in your organization.

Early in my career, I thought that leadership was what the people at the very top of the organization did and that management was what all of the people in the middle of the organizational structure did. However, while this positional view is correct in many organizations, it does not need to be that way. Management and leadership are both necessary components of a successful organization of any size.

The differences between leadership and management

The role of a leader in any organization is to set the direction. A leader is the first to envision a future position for the organization and first to evangelize that position. Leadership is about finding a point on the horizon and saying, loudly and firmly, we should go there.

Management focuses on keeping the ship upright and moving in the direction that it’s headed. It’s not about picking a point on the horizon and going there. Management is about plotting progress towards the spot on the horizon.

More…

Anatomy of a Software Development Role: Project Manager

Robert Bogue August 11, 2005 No Comments

The Project Management role is the first role in the software development process that isn’t on the main line. The project manager isn’t a person doing “real work.” The project management role is one that is designed to help ensure that the software development process works as it is intended. The project management role works closely with the development management role in order to facilitate, encourage and prioritize the process.

The project management role is perhaps the most clearly defined role within the software development process due to the development of project management as a profession. (If you’ve not been following the series, you might want to read Cracking the Code: Breaking Down the Software Development Roles.)

While the software industry is nascent, the project management industry is enjoying the advancement of a powerful organization in the Project Management Institute . They have assembled a guide to the body of knowledge for the project management profession that is often referred to as the PMBOK Guide. This organization has developed a widely recognized certification, Project Management Professional (PMP), which has both practical experience requirements as well as traditional testing requirements.

http://www.developer.com/java/ent/article.php/3526491

Open source software on the desktop — Is it right for you?

Robert Bogue August 9, 2005 No Comments

Thinking of switching to open source? Don’t underestimate what the true acquisition cost will be.

There are few topics more heated than the discussion surrounding Open Source vs. Microsoft. This discussion typically focuses on the difference between Linux and Windows as an operating system. This is, however, only one dimension of the problem. You have to consider both the operating system and the office software that most users use. You must add to that everything else you have to support that isn’t included in the basic office applications.

Comparable and compatible

One of the arguments towards placing open source software on the desktop is that it’s “comparable and compatible.” Comparable means it’s largely similar; it performs the same functions. Compatible is saying simply that it works with the recognized leader in the area (Microsoft). For instance, Linux is comparable to Windows in that it’s an operating system. It’s compatible because it can read and write files to a Windows-based server (through Samba and some configuration.) Similarly, OpenOffice is comparable to Microsoft Office in that it offers the same basic functions. It’s compatible in that it can read and write Microsoft Office files.

The rub comes in when you evaluate how comparable and compatible the solution is. From a comparable standpoint, does the solution offer the same user experience in terms of ease of use? How much will change from what’s already familiar? How about help? Despite the challenges with the help in commercial systems, it’s substantially better than the help files that exist for open source software.

http://www.techrepublic.com/article/open-source-software-on-the-desktop-is-it-right-for-you/

Develop a strategy for requirements gathering

Robert Bogue August 2, 2005 No Comments

There’s more to requirements gathering than getting an initial framework. Understanding the differing goals of the requirements process is an important key to understanding how to get requirements done right.

In most mid-sized IT organizations the process of gathering requirements is a little more advanced than scribbling a few wire frame representations of what the screen for the new system should look like. (A wire frame is simply a line drawing with boxes, rectangles, and text which roughly describes what the final product may look like.) This mechanism for collecting requirements is quick. After a few minutes and a handful of sketches, enough information can be gathered to start developing a solution.

While this may be required for some projects, it’s more often than not going to create more challenges down the road as small details escape everyone’s attention until very late in the process — where changes and fixes cost the most money.

This technique does have its place. It’s a necessary part of the overall process. However, there’s more to requirements gathering than getting an initial framework. Understanding the differing goals of the requirements process is an important key to understanding how to get requirements done right.

http://www.techrepublic.com/article/develop-a-strategy-for-requirements-gathering/

Anatomy of a Software Development Role: Training

Robert Bogue July 27, 2005 No Comments

Wrapping up the software development lifecycle and turning over the completed product to the users is the training role. The training professional is the last one in the process since they are the ones who get the mass of users to use the software that has been created. Their purpose is to help the users understand how to use the software that’s been created. (If you’ve not been following the series, you should read Cracking the Code: Breaking Down the Software Development Roles.)

What’s the Training role?

The training professional first and foremost creates the materials necessary to train users how to use software. For that reason, training professionals are often tapped to create user documentation and help files in smaller organizations.

The training professional is ideally someone who has an instructional design background and therefore understands how to create materials that are effective in helping adults learn. They are also, ideally, someone who can approach the problems that the software solves in a way which makes sense to the users. Click here to see how the Deployment role fits within the full organizational chart.

http://www.developer.com/java/other/article.php/3523171

Four Things you’re missing in your backup strategy

Robert Bogue July 26, 2005 No Comments

Backup Strategies aren’t always about when to backup and what to backup. They are often about how to create the right systems to allow you to discover problems when they occur.

When most people think of a backup strategy they think about tape rotation and backup schedules. While these are important parts of a backup strategy they’re not the whole story. As an organization begins to assimilate more and more servers, a reliable backup strategy becomes more challenging. Instead of one tape drive that backs up the entire network, libraries become necessary. Instead of doing one backup job and schedule, you need several. Here are four fundamentals for developing your backup strategy.

Plan for growth

Most organizations have begun to start monitoring their disk storage needs. While disk storage is cheap, the cost of maintaining all those files, including archives and backups, starts to become a real expense. When an organization plans its disk needs, it needs to review its growth and determine how much extra disk space will need to be purchased over the next year.

But here’s the rub. Adding more disk space is relatively easy. You just add new drives to the disk array or you swap out smaller disks for larger ones. The process takes time but it’s relatively transparent. Upgrading tape capacity isn’t so easy for most organizations.

http://www.techrepublic.com/article/four-things-youre-missing-in-your-backup-strategy/

Four steps for reducing project risk

Robert Bogue July 19, 2005 No Comments

Risks in a project are inevitable. However, carefully collecting, evaluating, prioritizing, and controlling risks can increase the chances of success for your next project.

Whether it’s small or large, complex or simple, every project has risk. It’s our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you’ll learn a simple four-step approach for doing just that.

Inventory

The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project.

http://techrepublic.com.com/article/four-steps-for-reducing-project-risk

Public Speaking