Mar 10, 2006
Managing Web Projects, Part IV
We continue the review of J. Rodney Turner's book.
In chapter 2, Turner discusses what distinguishes web projects from other projects, especially other IT/IS projects. He argues that web projects are a subset of IT/IS projects but have enough differences to make them distinct. When Turner writes that there are at least 10 key differences, I thought that would be a large number. After all, besides the technology used, how else are web projects different from IS project, as projects?
The key differences he lists include:
- shorter time horizons
- global reach with diverse user requirements
- managed from outside the IS department
- multidisciplinary teams with high focus on creativity and usability
- wider range of user requirements
- diverse technologies
- immature industry with skills shortage
- undefined methodologies
- fast changes in the industry
- perceived greater risk.
Note that the focus of the distinction is on the project, and not the product itself. That is, the focus is on the experiential difference in the undertaking of a web project versus that of a typical IS project.
Mar 4, 2006
Managing Web Projects Part III
Chapter 1 of the book comes before Part I and is intended to be a brief introduction to project management. While it's generally an excellent coverage with lots of useful insights, I'm not sure about the wisdom of trying to introduce project management in such a short chapter. Especially when you give a definition of what a project is that is almost heretical:
I think the chapter needed more space -- the subject it tries to cover is too big and only very briefly touches on the obligatory discussion of a project life-cycles.
There is a brief discussion on the importance of seeing a project at various levels, and some advise against prematurely planning the lower levels of a project before the higher levels are clearly understood.
His discussion of business objectives are also useful. Business objectives are the reasons why the organization is spending time and resources on the project, and they are different from the project objectives. Only after and if the project gets finished does the business begins to reap the business objectives.
A short and sweet discussion of the difference between cultural objective is also presented. Projects often focus only on the technical objectives ('build and install software') and the cultural objectives ('user training', 'creation of new procedures because of the new software'). This is a good reminder for the project planners.
Some of the valuable insights come from his discussion of project typologies. For example, he presents a typology of a project's importance to the business. Is the project intended to keep the business alive? Is it intended to reposition the business? Is it intended to improve business performance?
Finally there is also a brief discussion on the uniqueness of a project. While linguists may get riled when some things are said to be more unique than others, the world of project management seems to have latched on to the word. Turner presents a typology based in the uniqueness of projects. The classifications range from Runners, which are projects that are very similar to other projects undertaken by the project team, to Repeaters , which are projects common to the organization itself, but not to the project team, to Strangers, which are less familiar to the organization, having undertaken a few similar projects, to Aliens, which are totally new projects. The importance of this typology is that it highlights the risk inherent in the type of project, with Stranger projects bringing the highest risk.
In chapter 2, Turner begins describing what is special with web projects.
A project is a temporary organization to which resources are assigned to undertake a unique, novel and transient endeavour managing the inherent uncertainty and need for integration in order to deliver beneficial change objectives (emphasis mine).
I think the chapter needed more space -- the subject it tries to cover is too big and only very briefly touches on the obligatory discussion of a project life-cycles.
There is a brief discussion on the importance of seeing a project at various levels, and some advise against prematurely planning the lower levels of a project before the higher levels are clearly understood.
His discussion of business objectives are also useful. Business objectives are the reasons why the organization is spending time and resources on the project, and they are different from the project objectives. Only after and if the project gets finished does the business begins to reap the business objectives.
A short and sweet discussion of the difference between cultural objective is also presented. Projects often focus only on the technical objectives ('build and install software') and the cultural objectives ('user training', 'creation of new procedures because of the new software'). This is a good reminder for the project planners.
Some of the valuable insights come from his discussion of project typologies. For example, he presents a typology of a project's importance to the business. Is the project intended to keep the business alive? Is it intended to reposition the business? Is it intended to improve business performance?
Finally there is also a brief discussion on the uniqueness of a project. While linguists may get riled when some things are said to be more unique than others, the world of project management seems to have latched on to the word. Turner presents a typology based in the uniqueness of projects. The classifications range from Runners, which are projects that are very similar to other projects undertaken by the project team, to Repeaters , which are projects common to the organization itself, but not to the project team, to Strangers, which are less familiar to the organization, having undertaken a few similar projects, to Aliens, which are totally new projects. The importance of this typology is that it highlights the risk inherent in the type of project, with Stranger projects bringing the highest risk.
In chapter 2, Turner begins describing what is special with web projects.
Managing Web Projects Part II
Continuing the review of J. Rodney Turner's book.
It seems many people who read books ignore the Preface. I'm not one of them, and I don't understand why people skip it. The Preface is the author's personal message to you, dear reader, about their intention in writing the book, and how they intend it to change you, as well as change you into what. Why would you not want to know about that?
Upon opening a book, I go directly to the Preface right after briefly flipping through the pages (mostly to filter out books that use size L or XL fonts). After reading the Preface, then I start to take in the smell of the paper, but let's not go into that.
In his Preface, Turner reveals that this book is the first of a projected series of books on specific applications of project management. Perhaps sensing that he needs to undertake a defense of the need for such a series, he elaborates that although he agrees with the opinion of many, that project management is a generic skill, nevertheless, different types of projects have different needs and therefore require different methodologies.
Comparing project management with other professions, such as medicine, law, and accounting, Turner observes that while these three, like project management, are generic professions, each has its own sub-specialty.
You probably do not want a specialist in corporate-law to defend you in a criminal case (viz. when Sherman's lawyer acquaintance turns him down in The Bonfire of the Vanities). Neither do you want a neuro-surgeon to deliver your baby (Dr. Brown of the Everwood TV Series notwithstanding).
Turner points out some revelations he had while researching and working on the book:
- General managers (rather than IS managers) tend to end up being handed responsibility for delivering web projects.
- Change management seems to be much more important than he initially thought.
- Web projects tend to be managed whole, rather than delivered piece-meal. In consequence, he discovers that techniques like agile management or extreme programming were not as central as he initially expected.
I was initially confused by those observations: why would piece-meal deliveries espoused by agile techniques not be central? Isn't the changing nature of web pages a perfect match for agile software development? And why would change management be important in a web development project where quick delivery is the expectation? Who has time for change management?
Peeking inside, I realised that in the context of the book, Turner was not speaking about simply developing web applications, but also about web-enabling business operations. That is why general management plays larger role. That is why change management is fundamental (not change control management, as I originally thought), and that is why the project tends to be delivered whole.
The type of projects covered by the book possibly makes this book less interesting for technical managers interested in managing web-based software alone, but it does make it more interesting to me.
In the next posting on this subject, we will look at chapter 1.
It seems many people who read books ignore the Preface. I'm not one of them, and I don't understand why people skip it. The Preface is the author's personal message to you, dear reader, about their intention in writing the book, and how they intend it to change you, as well as change you into what. Why would you not want to know about that?
Upon opening a book, I go directly to the Preface right after briefly flipping through the pages (mostly to filter out books that use size L or XL fonts). After reading the Preface, then I start to take in the smell of the paper, but let's not go into that.
In his Preface, Turner reveals that this book is the first of a projected series of books on specific applications of project management. Perhaps sensing that he needs to undertake a defense of the need for such a series, he elaborates that although he agrees with the opinion of many, that project management is a generic skill, nevertheless, different types of projects have different needs and therefore require different methodologies.
Comparing project management with other professions, such as medicine, law, and accounting, Turner observes that while these three, like project management, are generic professions, each has its own sub-specialty.
You probably do not want a specialist in corporate-law to defend you in a criminal case (viz. when Sherman's lawyer acquaintance turns him down in The Bonfire of the Vanities). Neither do you want a neuro-surgeon to deliver your baby (Dr. Brown of the Everwood TV Series notwithstanding).
Turner points out some revelations he had while researching and working on the book:
- General managers (rather than IS managers) tend to end up being handed responsibility for delivering web projects.
- Change management seems to be much more important than he initially thought.
- Web projects tend to be managed whole, rather than delivered piece-meal. In consequence, he discovers that techniques like agile management or extreme programming were not as central as he initially expected.
I was initially confused by those observations: why would piece-meal deliveries espoused by agile techniques not be central? Isn't the changing nature of web pages a perfect match for agile software development? And why would change management be important in a web development project where quick delivery is the expectation? Who has time for change management?
Peeking inside, I realised that in the context of the book, Turner was not speaking about simply developing web applications, but also about web-enabling business operations. That is why general management plays larger role. That is why change management is fundamental (not change control management, as I originally thought), and that is why the project tends to be delivered whole.
The type of projects covered by the book possibly makes this book less interesting for technical managers interested in managing web-based software alone, but it does make it more interesting to me.
In the next posting on this subject, we will look at chapter 1.
Subscribe to:
Posts (Atom)