Category Archives: Project Management

Project Management

Project management at home: the network panel challenge

Home network panel at beginning of projectI’ve started noticing how I’m tackling projects at home much like I do at work. At work, I’m the guy that gets called up to clean up messes — a janitor of sorts — because some projects don’t run perfectly. It requires strong analytical skills which is my strong suit. Based on my experience, jumping into the middle of a project requires three things:

  1. Ensuring that you don’t waste time on the “blame game.”
  2. Identifying a path to take the project from the current state to the end state.
  3. Keeping the team focused on their goal avoid another project “derailment.”

So following these same steps, I decided to tackle our home media network panel (see image above). The network panel was organized in such a way that the wires from each room were bundled together. While in theory it sounded logical as the wires originated from the same outlet, the panel was very difficult to manage because the bundled wires from each room had to be split up and terminated into the same module. For example, the coax wires from the office and the living room, which were bundled with the telephone/satellite/network wires from the same room, had to be bundled together and terminated in the coax cable splitter module.

Continue reading

The traits of modern web developers

One of my favorite blogs on software development is Jeff Atwood’s Coding Horrors. Jeff is a programmer turned blogger that has a unique (and real) perspective on the psyche of developers. His blog posts are based on a topic that he’s researching for work or fun, which is something that I also do regularly.

In a recent search, I came across a blog posts from 2006 on “modern software development” (source) where Jeff he explains that development really hasn’t changed much in the past ten years. Based on my experience of working with developers both on client and agency side, I think that he’s spot on. Looking at his list, I came up with only a single addition (which appears in red/bold) for traits of modern developers:

  • Store code in a source control repository. The beauty of using source control solutions, such as SVN/subversion, Git, or Visual Source Safe (VSS), is that a team of developers can develop code without overwriting each the changes made by each other.
  • Deploy code using scripts. With a script, developers can automate the launch of a website, this ensuring that nothing is missed in the process.
  • Develop using TDD or Test-driven development. Instead of writing code first, developers focus on writing tests for their code. This provides a solution to limit the number of bugs as a unit test can also serve as a low-level regression test as new code is introduced.
  • Reuses code when possible. Modern developers know that they don’t need to re-invent the wheel. Instead of rewriting code, they tend to reuse code that’s already working. This translates to saving development time, plus it allows developers to focus their energy on learning something new.
  • Apply the Model–View–Controller (MVC) architectural pattern. Since code is logically separated into 3 tiers (data layer, presentation layer, and business layer which connects the other two), developers can more easily maintain their code.

The good news is that the barrier to become a modern developer is low. Old school developers only need to adopt the MVC pattern to be new again.

Stonehenge

NOTE: Stonehenge photo was provided by Danny Sullivan.

Web Projects Planning and the Iron Triangle

The Iron Triangle allows for only two factors in determining the success of a web project. But the impact of the client’s perspective on the triangle seems to reduce the two factors into a single option.

Iron TriangleEarly on in my development career, I leaned how the Iron Triangle impacts projects. The iron triangle (aka the Project Triangle) is a software development concept that says that the quality of a project is determined by three factors:

  • Timeline. How long you have to complete a project?
  • Budget. How much is the client is willing to pay for the work?
  • Features. What functionality can be built?

The point of the Iron Triangle is that you can pick or constrain only two of these three factors. So if the project timeline and features are constrained, then the budget must grow. If all three factors have to be met, then the quality of the web project will be sacrificed. While this concept seems to give developers some breathing room, the Iron Triangle seems to be further constrained when the client’s perspective is taken into account. Let me explain.

A client typically approaches web projects with two constraining factors. When a client requests a solution, they normally constrain the project by asking that the solution be delivered by a certain deadline. The deadline is normally set because the client needs to meet a pre-determined objective, such as seasonal promotion, customer acquisition campaign, etc. Additionally, when a client requests a solution, they further constrain the project with their budget. Since money doesn’t grow on trees, the client will dictate how much they can spend for development on a project to be completed.

So when the client’s constraints on a project are taken into account, the Iron Triangle is actually reduced to a single option: project features. This means that developers have to look at how many features they can implement for the time and money that they are given. The good news is that the feature list can be functionaly robust or weak. That means that there’s some play in what the client will or will not get for the time and money that they’re dedicating to the project.