There's a good posting over at AngryCoder.com about the problems inherent in fixed bids for project work. Although the author acknowledges that hourly billing can also be full of challenges, he indicates an overall displeasure with fixed bid billing.

As the job market fluctuates, companies and the managers within them pay more or less attention to motivating and rewarding their employees. In the case of IT projects, how well developers are motivated an rewarded has a direct impact on the outcome of the project. A recent research project by Robert C. Mahaney and Albert L. Lederer reveals that intrinsic rewards have a different effect than extrinsic rewards.

According to InfoWorld, "Too many organizations unwittingly give their competitors a free kick by having Web sites that are low on usability and high on annoyance."

An interesting thing is happening with the many outsourcing deals struck in the last several years. Rather than costing less, outsourced software projects are exceeding their budgets and are often riddled with bugs. What's interesting is that there are indeed cost savings in the early years of outsourcing deals, but these savings often disappear in the fourth year.

Another project manager whose blog I read covered a topic recently that really resonated with me. He covered the idea that it's foolish to try and put a percentage complete note beside a task.

In a previous post, I summarized a real world methodology for web projects. In that first post, I described the phases that make up a project. This second posting summarizes what can be viewed as 9 mini-methodologies each delivering an element of the overall business solution.

A medium-sized consulting company I once worked developed their own methodology for dealing with web development projects. This company has since gone out of business making their methodology public.

Let's face it, a web page as a user-interface is pretty limited. For many years, big companies like Apple and Microsoft spent millions on developing the user interfaces for their software. Applications were responsive to user actions and it was usually the user that couldn't keep up with the computer. Then along came the world wide web and we threw much of that research out the window. We somehow gave up productive user interfaces in exchange for slow-to-respond web pages that always needed to make a round-trip to the web server to process every interaction. Billion dollar businesses were built on this set back in user experiences.

Just about every time Microsoft has bested a rival, it has been because they played the platform card. With a platform, Microsoft was able to eliminate even the most dominant applications. For example, Windows, the platform, allowed Microsoft to displace Lotus 1-2-3 with Excel, WordPerfect with Word, and Netscape Navigator with Internet Explorer.

According to CIO Magazine, testing (after requirements) is the most overlooked, most under funded, most rushed, yet most critical aspect of the software development cycle. I'd have to agree. I'd even argue that software testing is in worse shape than requirements. The article lists 11 ways to boost testing success, but I'm only posting the 3 that really resonated with my experiences.

Bill Vass, CIO of Sun Microsystems took some time to relate 10 essentials for successful IT operations. The list appeared in the October 1, 2005 issue of CIO Magazine. Here they are.

Moez Chaabouni, CIO of Hondros College, wrote a letter to the editors of CIO magazine that I really liked. I'm posting it here verbatim because I'm sure I'd butcher his message if I tried to paraphrase it.

A CIO article relates a story about a young engineer on his way up the ranks in corporate America. One day his boss told him that he'd need to improve his business memo writing skills or else jeopardize his continuing advancement. Since communication skills are often cited as key to one's ability to get things done, it's not much of surprise that memo writing plays a big role. And it's no surprise that an IT worker had problems communicating to his memos' audience i.e. business-minded senior management and executives.

Jerry Madden, a retired employee of the Goddard Space Flight Center, collected over 100 "lessons" learned from project managers he worked with over many years. Some of the items were pretty specific to the space industry or to projects involving government programs, but there were certainly some good nuggets in the lot. Here are some of the items from his list that resonated most with me and my experiences.

I stumbled on a long list of tongue-in-cheek, project management truisms the other day. These were meant to be funny, but they sure hit the nail on the head. Here is the second batch of 21 from the list.

I stumbled on a long list of tongue-in-cheek project management truisms the other day. These were meant to be funny, but they sure hit the nail on the head. Here are the first 21 from the list.

Depending on your experience with service level agreements (SLAs), you either love them or hate them. Proponents of SLAs argue that they force IT workers to become customer-friendly, business-savvy employees. Opponents of SLAs feel that they just force IT departments into positions of subservience to the business and perpetuate the stereotype that IT departments are service providers rather than business partners.

According to a survey done by CIO Magazine in February 2005, these are the top-10 things that IT leaders consider to be the most effective at changing the perception of IT within a company. My comments (in italics) follow some of the bullet points.

In the feedback section of a magazine that I read there was an interesting perspective that at first blush seems like a new idea, but I think is just a matter of semantics. Dan Crawley, an IT Manager, suggests that, "There is no such thing as an IT project excluding basic things like regular maintenance. Any project or initiative should have a specific business purpose, and therefore be acknowledged as a business project and led by someone outside of IT."

A recent issue of CIO Magazine offers these 10 tips for ERP implementations (see ERP definition).

There's a lot that's been written about project management. And there will undoubtedly be more. But after being both a software developer and project manager for 10 years, it has become obvious that there are some things that are just common sense that one should keep in mind.

Like other project management books, Lessons in Project Management pushes a particular methodology: TenStep Project Management Process. It happens to be a good methodology that recognizes the need to deal with projects of all sizes. For instance, the methodology states that a project definition is always required, but there isn't always a need for a metrics process. Or that it is always important to watch out for scope creep, but not always important to create an exhaustive list of risks.

If you've already decided that you want to build a web site for your business, then you should also start thinking about how you're going to manage changes and updates to keep the site relevant which will keep customers coming back.

According to Construx Software's Professional Software Engineering Pyramid, only about 3% of US-based developers read books on software engineering. There is a lot to be learned from the experiences of others. Particularly from those
that have been doing something longer than you have. Here is a list of books
that have prevented me from wasting months and even years working out the solutions to
common software development issues. With solutions to the common issues in hand, I am able to
focus on the unique, project-specific obstacles I encounter when building software
applications.

So you're thinking of building a web site of your own. My guess is that you're considering a brochure, e-commerce, or community site (read Five Types of Web Sites for a description of these types of sites). You're going to go through the same steps regardless of the type of site. However, the size of your endeavor will determine with one or two people handle all the web development tasks or if you'll need the services of a large number of people.

If you've been surfing the web for any length of time you'll probably agree with the statement that no two web sites are the same. However, beneath the surface, many web sites share some similarities. It only takes a handful of categories to classify 99% of the web sites that you and I are likely to visit.

There seems to be a never ending discussion about software quality. Depending on who you ask, you'll be told that software developers should be proud of their work or embarrassed by it. Regardless of the side you happen to be on, you'd probably agree that software can be better. Or rather, the way software is written can be improved.

I've just about finished reading Steve McConnell's Professional Software Development book. I'm far enough in to the book to know that I'm not going to get nearly as much out of it as I did from Code Complete. Which isn't to say that there isn't anything valuable in it.

I've been making my way through Agile Software Development Ecosystems by Jim Highsmith. This book provides an overview of agile software development methodologies and includes a brief description of the 7 most common methods. Of these 7, Extreme Programming (XP) was the most familiar too me. The biggest problem I have with XP is that it advocates pair programming. That idea in itself isn't the problem. The difficulty lies in trying to convince upper management that having two developers at one computer is an effective use of resources.

Gartner has recently re-enforced something I've suspected for quite sometime: technical aptitude is no longer enough to secure a future for IT professionals. That should be a pretty scary statement for a majority of the IT folks out there who generally like to be left alone to do their own thing. Gartner is expecting the "emergence of a new breed of IT professional, the 'versatilist', who will have technical aptitude, local knowledge, knowledge of industry processes and leadership ability."

Years ago I read Code Complete from Steve McConnell. It is one of my favorite software development books that isn't programming language specific. I think it's such a great piece of work that whenever a client of mine starts to talk about coding standards, I suggest they buy a bunch of copies and distribute them to their software developers. Ten copies of the book will cost less than a single 1 hour team meeting. And having a book means being able to point to and reference things that would otherwise get lost in meeting minutes.

I remember a long time ago that I looked in to how one would make a Visual Basic application run as a Windows service. I didn't actually need to do it at the time, but I was curious. Well, today, I needed to do it. Apparently it's a bit of a big deal because of the threading model used by Visual Basic.

ComputerWorld recently posted a list of 10 computer skills that are largely irrelevant when compared to other more popular technologies. Among the list are a handful of programming languages. Some of these I have no experience with while others are ones I'm happy to see go away.

I came across an interesting article on CNN Money yesterday. I found it interesting for two reasons: 1) There's the potential to make a lot of money on the Internet and 2) SEO, SEM, and affiliate marketing aren't the be all and end all of monetizing the web. The proof comes from Kevin Ham who has amassed a $300 million portfolio of domains.

Andres Taylor recently wrote an excellent article about 10 things he learned from being a professional software developer. His list was inspired by Michael Bierut's list of things he wasn't taught in design school. Both lists resonated with me and if you've been in the corporate world for several years I imagine you'll agree with many of their observations. I'm going to highlight the three items I particularly agree with.

So I'm getting ready to deploy an application to a client's QA team and I've decided that I'm not happy with the Packaging and Deployment Wizard included with Visual Studio 6.0. I guess technically it does the job, but it doesn't do it very well and making changes is a hassle.

I recently re-entered the job market. Having been several years since I last looked for work, I wasn't sure what sort of environment I was about to step in to. I had a sense that the market was good, but there was no way to be certain without actually starting the search.

For a little while now I've been trying to decide how Rational (now part of IBM) could be so successful at pushing their monolithic, process-laden software development methodology, especially in the face of increasing evidence that such methodologies aren't particularly useful. The answer to this came from Jeff Sutherland of SCRUM fame. He recently posted a link to a PDF titled How to Fail with the Rational Unified Process: Seven Steps to Pain and Suffering. Basically, my understanding of the RUP was incorrect and that most implementations of RUP are faulty.

There's an article over at CNet about outsourcers and their attempts at distinguishing themselves from the rest of the pack. Most of the article is of little interest, but there was one part that got me thinking.

I came across a discussion recently (I can't remember where) about how the typical comparison between writing software and building a house is flawed. The article was pretty compelling, pointing out that because a building is something very tangible and physical, it doesn't actually compare very well to software.

A couple of years ago the Agile Software movement was starting to take shape. I heard about it back then, but didn't pay it much attention. I even attended a presentation put on by one of my clients where they tried to convince their NY office to adopt the processes described by Extreme Programming (XP). At that time I didn't have much of an opinion about XP, but I did know that it would be a hard political battle to convince the powers that be that this was worthy of their time.

The power failure in NY had one good consequence for me. Without power I couldn't use my computer or waste time in front of a TV. There was nothing else to do except read. So I dug in to my pile of unread Software Development (now merged with Dr. Dobb's) magazines and started reading.

Part of learning a new programming language is adopting the various industry best practices. The naming conventions used during software development can have a huge impact on future maintenance efforts. If no rules are followed then it becomes that much harder to read the code and figure out what is going on. This particularly important as developers with different skill sets come and go from IT departments.

In Volume 47, Number 11 of the Communications of the ACM, Amrit Tiwana and Mark Keil reported on some results from a study of the relative importance of 6 project risk drivers. They were surprised that the most critical risk driver was actually the choice of methodology rather than a seemingly more common complaint such as constantly changing requirements.

George Litwin and Robert Stringer of Harvard Business School studied the behavior of managers as leaders in various settings. They concluded that managers exhibit a variety of patterned behaviors that can be described generally by one or more of 6 fundamental managerial styles.

I purchased Larry L. Constantine's book, The Peopleware Papers: Notes on the Human Side of Software recently. This book is a collection of 60 or so essays that were previously published several years ago. The essays focus on the people aspects of software development and so are as applicable today as they were when originally published.

A project manager's primary role is to be a facilitator with the goal being to ensure that a project is completed on time, within budget, and according to the requirements. As you might guess, being a facilitator can mean wearing many hats.

According to Forrester research, the future of technology related careers will include moving in and out of the IT department. Gone are the days where one would start out as a programmer and move up the ladder from there.

As you might expect, a web developer is one who builds web sites. However, a good web site builder has much more to offer than just the technical skills needed to put a web site together.

Every now and again I read someone's description of a software problem and I realize that I too have faced the same issue. Such was the case with Object Relational Mapping. Many of the software projects I've worked on have presented this challenge of how to map objects to database tables. And in each case my team came up with a solution that worked. What I didn't realize at the time was that the problem and solutions I used solve the problem were common enough to be given a name.

In today's LED-Digest, there's a discussion about the merits of fixed-width designs vs. fluid layouts. For the most part, people on the list seem to prefer fixed-width. Here are two comments from members explaining why.

A recent Forrester Research survey found that IT decision-makers at both small and medium companies think that their IT shops are best at supporting tactical efforts (e.g. improving efficiency). However, when it comes to innovation and other strategic contributions, the IT teams fall short.

The following is the second in a two-part posting on negotiation. This commentary was taken from Nick Jenkins' A Primer on Project Management. In it, Nick does a good job of covering the facets of negotiations. His primer was distributed
under the creative commons license and as such, the following is also subject to the conditions of the creative commons license.

Some co-workers of mine went to a web site usability session conducted by a director from the Mequoda Group and came back with some materials that I've been perusing. This material has some good descriptions of the types of web sites that exist today that I think are worth describing here. This final part in a three part series covers the lead generation and brand building web site models.

Some co-workers of mine went to a web site usability session conducted by a director from the Mequoda Group and came back with some materials that I've been perusing. This material has some good descriptions of the types of web sites that exist today that I think are worth describing here. This second part in a three part series covers the membership and classified web site models.

Some co-workers of mine went to a web site usability session conducted by a director from the Mequoda Group and came back with some materials that I've been perusing. This material has some good descriptions of the types of web sites that exist today that I think are worth describing here. This first part in a three part series covers the product marketing and catalog marketing web site models.

When you think of open source software, you don't generally think of companies making money from it. True, there are some pretty big players such as Red Hat that distribute and support versions of Linux to corporations. But they used to be few and far between.