History is littered with IT application projects that end late, go way over budget, or abandoned altogether.  I was fortunate enough to see one work out really well (almost – please read on).  It was no mistake.  It came down to a simple method advocated by a gentleman named named John Carpenter.

The project was an HR management software conversion from one commercial off-the-shelf software (COTS) package to another.  The company concerned was conservative about spending money.  A previous business case had proposed a similar project.  The problem with that business case was that the benefits were really tough to conceptualize, so the cost/benefit analysis relied on soft benefits like “improved access to information” and “more consistent reporting data”.  The folklore was that the CFO had physically thrown that business case out of his office. Continue reading »

 
Excerpt from Illusions, Allusions – Let’s Get Real about Database Design, InfoManagement Direct, October 4, 2002

Excerpt from "Illusions, Allusions – Let’s Get Real about Database Design", October 4, 2002

Much of today’s IT application development – custom or off-the-shelf – involves integrating data from legacy systems, third- party software products and external data sources such as demographics or mail lists.  More often than not, data integration is unexpectedly complex, either due to data quality issues or the nature of the data integration itself. Continue reading »

 

Not everyone gets to be a leader, and most leaders are also followers in their own right.  The project manager follows instructions from the project sponsor, the CEO from the board, the politicians from the polls, and so on.

Followership is the yang to leadership’s yin, and according to many interesting sources following can be as fulfilling and important as leadership. For example, check out this site: http://www.exe-coach.com/followerPartnership.html.  Quoting: “When both the leader and follower are focused on the common purpose a new relationship between them arises. This new relationship is candid, respectful, supportive and challenging. It is a relationship that honors open communication, honesty and trust from both parties.“  The article argues that effective followership is the key to making today’s flat organizational models successful and mitigating risk of corporate malfeasance and scandal.

Think about it: more people are followers than leaders, so isn’t it more important to cultivate effective followership than effective leadership?

 

Recently I was asked for a high level requirements plan for a large IT conversion.  I googled around a little for something standard.  I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people.   I then rifled my files to find the example below. Continue reading »

 

I’ve heard that “A good project manager can manage any project, as long as they’ve got good people on the project”. In the perfect world, maybe. In the real world, no way.

Those promoting project management focus on characteristics of PMs that are common across all disciplines: interpersonal skills, organizational skills, communication skills, and problem-solving skills.  These are necessary but not sufficient qualities.  Good project managers also have interest and depth in the subject matter of the project.

It seems that the world has forgotten about history’s great project managers. They were overwhelmingly individuals with abiding interests in their fields.  Werner von Braun led the massively successful development of the Saturn moon rocket. General Bernard Schriever, the man cited as “The Father of Project Management” (here), who led the Air Force’s space and missile programs in the 1950s, was a long time pilot with an engineering degree.  Frederick Brooks, with a PhD in Mathematics from Harvard, led development of IBM’s OS/360 operating system, fundamental to IBM’s dominance 0f commercial computing during the 70s and 80s. “As of 2008 he is still engaged in active research there, primarily in virtual worlds and molecular graphics.” (Wikipedia)

I recently witnessed two IT projects, both multimillion dollar efforts and both business-critical.  Project A, a migration to a commercial-off-the-shelf (COTS) human resources system, tracked to budget and schedule and met business objectives with almost no customization.  Project B, another COTS effort for core business operations, suffered huge budget and schedule overruns associated with frequent changes in direction and scope expansions.

Project A was outsourced to an outside consulting firm, who brought in a PM with deep technical experience configuring and customizing the COTS package.  Project B was run by an internal Project Management Office, staffed by project managers who did not have technical or business analysis backgrounds.

Project A’s leadership had the background to understand the road ahead, and spent six months of a two year project in definition, completing detailed business requirements, business process design, and system architecture deliverables.  On Project B, a senior IT manager decreed that the team skip requirements definition, since future business processes would be dictated by the COTS application: a critical early mistake.  Project B’s management did not have the IT background needed to recognize the mistake, which would have been obvious to the Project A team.

For a PM to be effective he or she needs sufficient knowledge to envision the end product in a scope and objectives document, create a work breakdown structure that makes sense to business and technical team members, and know which risks are pivotal and which don’t matter.

In spite of stereotypes about IT folks, many are experienced, articulate, well organized, have great interpersonal and problem-solving skills, technically curious, and would welcome an opportunity to lead an ambitious project.  Make one of them your project manager, provide strong organizational support, and you’ll be more likely to achieve objectives on budget and on schedule.

 

An architectural template is a generalized architecture that illustrates features common to all examples of a given type of system. A template may be thought of as a “fill in the blanks” form for a project lead, identifying typical components, good analysis and design techniques, general project planning guidelines, staffing skill needs, and more. The data warehouse model is a good example (check out the Wikipedia article on data warehousing). It identifies distinct components and interfaces that make up a data warehouse, and defines the quality and performance characteristics that make them work well.
Most importantly, the template gives rules for deciding whether or not a system is an example of the given architectural type. With a good template, it is possible for a systems architect to compare the template with the general functions and objectives of a planned system. If the problem matches the template, then the architect has a head start on planning and definition.

© 2011 Bob Lambert Suffusion theme by Sayontan Sinha