Unfortunately the first chapter is pretty general, by necessity (have to do some context setting, can't just jump right into pros-and-cons of open source, or obscure security protocols). The later chapters (for example, Chapter 6 IT standard setting, or Chapter 10 Vendor Selection) are very specific and prescriptive.
As practitioners (we use the book for our internal training in the IT turnaround and management practice), it was important that the book contain actionable, specific advice. Otherwise it is indeed "one more high-priced, prettilly wrapped hunk o' junk" - an outcome that I truly believe we have avoided.
A three thousand dollar executive training session sounds about right, but first things first!
John
We highlight/. (among other blogs) in the book because, notwithstanding some notable exceptions, overall the forumers are insightful, knowledgable, and helpful.
Because of good response from Slashdot (apparently, since this review came on today) the book is right now #25 on the amazon.com business books list! Thank you.
Since Slashdot is a personal favorite of mine, and it was a good source of information for us as we researched our book, I will also make this offer to any slashdotters - if you buy the book (you can go from here or www.exec-guide.com) and email me a copy of the order at john.baschab@impactinnovations.com (please use the subject: Slashdot), I will send you a second autographed copy for free.
Thanks for all the comments here - please keep 'em coming.
In fact, it is not only making the business case for projects, but also ensuring that demand on the overall IT department and prioritization of the projects that IT will work on (based on the business case and other factors) is one of the most important areas where IT departments go "wrong."
This is a real focus of the book, and therefore we worked to weave the concept throughout. It is covered in some detail in Chapters 1, 2, 3, 6, 7, 8, 13, 17 and most exhaustively 15 (IT Demand Management and Project Prioritization)
As big Slashdot fans, we covered using/. and other user-contributed/moderated news sources in three chapters of the book.
If more standards committees, vendor selection boards and the like would consult/.'ers (or other vendor-neutral blogs) they would get closer to the straight story. Unfortunately, in many IT departments, the standards setting process starts with "what brand does my nephew like" and the information gathering process begins with "call the vendors since they know best."
The signal-to-noise issue, is of course, a well known phenomenon! Luckily Slashdot has great tools to help filter responses.
Thats actually true, although I had forgotten about it until now.
Just for kicks (and to prove some legitmate tech cred), here is a little of the source code for the TRS-80 Model III (and IV / 4p) file attribute modification program (part of the overall debugger mentioned above). Mind you, this worked in LDOS as well as TRS-DOS. I even managed to find a use for XOR;)
COM Copyright (c) 1986, John D. Baschab All rights reserved. COM FATMOD/CMD By John D. Baschab ORG ORG 0A000H
SAVSCR SCRBUFF Initialize variables. START LD IX,STORAGE
LD C,14; SVC @DSP; SVC @CLS
PRT OPNMSG Scroll protect screen.
LD B,7; LD C,3; SVC @VDCTL Get a drive number for the target file.
CALL GETDRV; PRT DWNMSG Read the directory of the selected drive into a buffer.
CALL READ Get the name of the file to change. INPFIL CALL FILSPEC See if it's there, and return it's location in IY.
CALL SCAN Display the files attributes for the user to edit.
CALL DISPLAY Get an option, (1-7). GETOPT
LD C,13; SVC @DSP; PRT OPTMSG; CALL GETINP
CP 0; JR Z,GETOPT
CP 8; JR NC,GETOPT
LD B,A Option number in B. Point HL to the place in the table of routines to the correct address. ALP1 points HL there.
LD HL,JPTBL-2 ALP1 INC HL
INC HL; DJNZ ALP1; LD E,(HL)
INC HL; LD D,(HL); EX DE,HL
JP (HL) Table for jumps to all the routines. JPTBL DW CPROT; DW CVIS; DW CACT; DW CDATE; DW DOSEXT; DW NFILE; DW NDFILE Change the protection level (0-7). CPROT
LD C,10; SVC @DSP; LD C,10; SVC @DSP Print all the available levels, using the ASCII messages.
LD HL,PRTTBL; LD B,8 PLP2
PUSH HL; PUSH BC; LD C,13; SVC @DSP
SPC 16; POP BC; SVC @DSPLY; POP HL
LD DE,14; ADD HL,DE; DJNZ PLP2
PRT CPTMSG Get the new level from the keyboard. INPL CALL GETINP
LD B,A; LD A,(IY+0)
AND 11111000B
ADD A,B
LD (IY+0),A
LD A,0E1H; LD (IY+16),A
LD A,0F8H; LD (IY+17),A
LD A,96H; LD (IY+18),A
LD A,42H; LD (IY+19),A Bytes written to the image of the directory in RAM. now write the RAM buffer back to the disk directory.
SOUND; PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY
JP GETOPT Toggles visibility. No user input taken for this routine, or the activity routine, because the status can only be two things - yes or no. CVIS
LD A,(IY+0); XOR 00001000B; LD (IY+0),A
SOUND; PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY; JP GETOPT Changes the activity. Dead files can be "de-killed", and active files can be removed. Toggles activity. CACT
LD A,(IY+0)
XOR 00010000B
LD (IY+0),A
PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY; JP GETOPT
These are good points. We actually included Slashdot (as well as a couple
of other blogs like f---edcompany.com and techdirt)
specifically in the book because they are terrific forums for the review
and critique of ideas in the field. Slashdot posters for the most part insightful,
intelligent and highly technically skilled.
Many vendor (or at least standards) selections
done in the corporate world could benefit from a few rounds of "ask slashdot."
Advice from the bloggers might not change the outcome, but the selection committee
would certainly wind up a lot smarter on the topic.
As far as OSS goes, it is an important topic. We address this in Chapter 6 - IT Standard Setting
(as well as tangentially in Chapters 10 and 11 on vendors management).
Although we don't speak to specific vendors, or OSS specifically, the standards chapter outlines a couple of key points:
1) You need standards to have a prayer of being effective
2) Standards covers a lot of areas, from development languages, infrastructure, facilities, security to hardware and applications
3) You better pick your standards carefully, because once picked, they are hard to unwind
4) You also have to be reasonable and know when to make exceptions to the standards
5) Above all, make the decisions in conjunction with the business then everyone will "own" the standard together
We cover the factors that need to be considered on (3) above (what to pick) in excruciating detail in Chapter 6.
The chart below is from chapter 6 and summarizes the key decision factors, as well as the primary and secondary criteria:
http://www.exec-guide.com/chart6_5.gif
We also cover product/service lifecycle analysis and how to make sure you are picking the standard at the "right" point in its lifecycle.
Slashdot Mirror
I agree (and already thought of that, and am trying), but, as you might guess, it can be a challenge to get such changes made! John
Source escrow is absolutely in. (Chapter 10). We have had the same experience, unfortunately.
Unfortunately the first chapter is pretty general, by necessity (have to do some context setting, can't just jump right into pros-and-cons of open source, or obscure security protocols). The later chapters (for example, Chapter 6 IT standard setting, or Chapter 10 Vendor Selection) are very specific and prescriptive. As practitioners (we use the book for our internal training in the IT turnaround and management practice), it was important that the book contain actionable, specific advice. Otherwise it is indeed "one more high-priced, prettilly wrapped hunk o' junk" - an outcome that I truly believe we have avoided. A three thousand dollar executive training session sounds about right, but first things first! John
Thanks for all the interesting comments.
/. (among other blogs) in the book because, notwithstanding some notable exceptions, overall the forumers are insightful, knowledgable, and helpful.
We highlight
Because of good response from Slashdot (apparently, since this review came on today) the book is right now #25 on the amazon.com business books list! Thank you.
Since Slashdot is a personal favorite of mine, and it was a good source of information for us as we researched our book, I will also make this offer to any slashdotters - if you buy the book (you can go from here or www.exec-guide.com) and email me a copy of the order at john.baschab@impactinnovations.com (please use the subject: Slashdot), I will send you a second autographed copy for free.
Thanks for all the comments here - please keep 'em coming.
John
Absolutely right.
In fact, it is not only making the business case for projects, but also ensuring that demand on the overall IT department and prioritization of the projects that IT will work on (based on the business case and other factors) is one of the most important areas where IT departments go "wrong."
This is a real focus of the book, and therefore we worked to weave the concept throughout. It is covered in some detail in Chapters 1, 2, 3, 6, 7, 8, 13, 17 and most exhaustively 15 (IT Demand Management and Project Prioritization)
As big Slashdot fans, we covered using /. and other user-contributed/moderated news sources in three chapters of the book.
/.'ers (or other vendor-neutral blogs) they would get closer to the straight story. Unfortunately, in many IT departments, the standards setting process starts with "what brand does my nephew like" and the information gathering process begins with "call the vendors since they know best."
If more standards committees, vendor selection boards and the like would consult
The signal-to-noise issue, is of course, a well known phenomenon! Luckily Slashdot has great tools to help filter responses.
Thats actually true, although I had forgotten about it until now.
;)
Just for kicks (and to prove some legitmate tech cred), here is a little of the source code for the TRS-80 Model III (and IV / 4p) file attribute modification program (part of the overall debugger mentioned above). Mind you, this worked in LDOS as well as TRS-DOS. I even managed to find a use for XOR
COM Copyright (c) 1986, John D. Baschab All rights reserved.
COM FATMOD/CMD By John D. Baschab
ORG ORG 0A000H
SAVSCR SCRBUFF
Initialize variables.
START LD IX,STORAGE
LD C,14; SVC @DSP; SVC @CLS
PRT OPNMSG
Scroll protect screen.
LD B,7; LD C,3; SVC @VDCTL
Get a drive number for the target file.
CALL GETDRV; PRT DWNMSG
Read the directory of the selected drive into a buffer.
CALL READ
Get the name of the file to change.
INPFIL CALL FILSPEC
See if it's there, and return it's location in IY.
CALL SCAN
Display the files attributes for the user to edit.
CALL DISPLAY
Get an option, (1-7).
GETOPT
LD C,13; SVC @DSP; PRT OPTMSG; CALL GETINP
CP 0; JR Z,GETOPT
CP 8; JR NC,GETOPT
LD B,A
Option number in B. Point HL to the place in the table of routines to the correct address. ALP1 points HL there.
LD HL,JPTBL-2
ALP1 INC HL
INC HL; DJNZ ALP1; LD E,(HL)
INC HL; LD D,(HL); EX DE,HL
JP (HL)
Table for jumps to all the routines.
JPTBL DW CPROT; DW CVIS; DW CACT; DW CDATE; DW DOSEXT; DW NFILE; DW NDFILE
Change the protection level (0-7).
CPROT
LD C,10; SVC @DSP; LD C,10; SVC @DSP
Print all the available levels, using the ASCII messages.
LD HL,PRTTBL; LD B,8
PLP2
PUSH HL; PUSH BC; LD C,13; SVC @DSP
SPC 16; POP BC; SVC @DSPLY; POP HL
LD DE,14; ADD HL,DE; DJNZ PLP2
PRT CPTMSG
Get the new level from the keyboard.
INPL CALL GETINP
LD B,A; LD A,(IY+0)
AND 11111000B
ADD A,B
LD (IY+0),A
LD A,0E1H; LD (IY+16),A
LD A,0F8H; LD (IY+17),A
LD A,96H; LD (IY+18),A
LD A,42H; LD (IY+19),A
Bytes written to the image of the directory in RAM. now write the RAM buffer back to the disk directory.
SOUND; PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY
JP GETOPT
Toggles visibility. No user input taken for this routine, or the activity routine, because the status can only be two things - yes or no.
CVIS
LD A,(IY+0); XOR 00001000B; LD (IY+0),A
SOUND; PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY; JP GETOPT
Changes the activity. Dead files can be "de-killed", and active files can be removed. Toggles activity.
CACT
LD A,(IY+0)
XOR 00010000B
LD (IY+0),A
PRT DUNMSG; PRT DWNMSG; CALL WRITE; CALL DISPLAY; JP GETOPT
These are good points. We actually included Slashdot (as well as a couple
of other blogs like f---edcompany.com and techdirt)
specifically in the book because they are terrific forums for the review
and critique of ideas in the field. Slashdot posters for the most part insightful,
intelligent and highly technically skilled.
Many vendor (or at least standards) selections
done in the corporate world could benefit from a few rounds of "ask slashdot."
Advice from the bloggers might not change the outcome, but the selection committee
would certainly wind up a lot smarter on the topic.
As far as OSS goes, it is an important topic. We address this in Chapter 6 - IT Standard Setting
(as well as tangentially in Chapters 10 and 11 on vendors management).
Although we don't speak to specific vendors, or OSS specifically, the standards chapter outlines a couple of key points:
1) You need standards to have a prayer of being effective
2) Standards covers a lot of areas, from development languages, infrastructure, facilities, security to hardware and applications
3) You better pick your standards carefully, because once picked, they are hard to unwind
4) You also have to be reasonable and know when to make exceptions to the standards
5) Above all, make the decisions in conjunction with the business then everyone will "own" the standard together
We cover the factors that need to be considered on (3) above (what to pick) in excruciating detail in Chapter 6.
The chart below is from chapter 6 and summarizes the key decision factors, as well as the primary and secondary criteria:
http://www.exec-guide.com/chart6_5.gif
We also cover product/service lifecycle analysis and how to make sure you are picking the standard at the "right" point in its lifecycle.