Use the window below to chat with me (if I'm online ...)
Use the edit nick field above to let me see your name.
cazh1: on Business, Information, and Technology
Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Saturday, June 28, 2008
IT and the Business are Closer Than You Think
IT and the Business are Closer Than You Think
A few passing observations from the last few months; contrary to what many (IT/business) folks believe, they are just as good or just as bad in managing processes and projects as their counterparts in (business/IT).
Problem Resolution is Everybody's Problem
A few weeks ago I was discussing issues that came up with one of our systems, and the team was a bit dismayed that the user community was still finding errors (we should be trapping for that stuff!) I pointed out that it's illogical to worry about stuff like this. We've implemented fault-tolerant systems that predict as many problem situations as we can think of, with lots of alerts and doublechecking built-in. If we can think of a problem, we will build a trap for it. It stands to reason, therefore, that the only bugs to appear are the ones that we couldn't anticipate - so the only people that will experience the bugs will be the people using the system.
It's inevitable that end users will find your problems, and that's nothing to be concerned about - we're all testers, and testing never really ends (in a continuous improvement environment). What you should be concerned about - how quickly we can turn around a fix for the problem? What is our total uptime? Do we see decreasing numbers of new problems, and zero recurrence of previously reported problems?
Truth be told, the onus of root cause is just as much on the business. Was this a scenario that could have been predicted? Were the requirements amd/or testing scenarios complete? (... apparently not ...) When projects are well run, and it's a true partnership between IT and the business, misses like these are everyone's problem.
Nature Abhors a Vacuum
Business managers may not understand the details of the technology they work with, but they certainly understand good management techniques. Try working with any manufacturing operations group and not going to them with metrics or KPIs (Key Performance Indicators). This is their bread and butter; they cannot understand how anyone could manage without some form of metrics. And if they see none, they will not only notice the problems, but will proactively look for issues, assuming things aren't under control.
On the other hand, if you have a reasonable set of metrics and are managing to them, they certainly can't accuse you of not following sound management principles. They may provide feedback that the quality of their experience is still not the greatest - but a structured, metrics-driven approach shifts the conversation to towards a discussion about best metrics to manage to, and not whether or not IT knows what they are doing.
In the End, We're All [Bad] Programmers
Check out this article from CFO.com, detailing a number of "worst practices" that folks in finance to see their counterparts doing that make them cringe. Sound familiar?
Poor Segregation of Data: Mixing critical values with complicated algorithms (business rules) makes for a delicate and hard-to-maintain spreadsheet (application).
Poor Documentation of Assumptions: when revisiting (cloning/debugging) this report, if you can't remember the original assumptions (design), you may need to rework (refactor) the entire thing
Poor Documentation of Constraints: complex worksheets with many simultaneous calculations would benefit from interim formulas in key cells (asserts) to test reasonable boundary conditions
Difficulties in Making Changes: spreadsheets and formulas can and should be structured to allow for foreseeable extensions and modifications (subroutines)
"Now It's Here; Now It's Not": at times it's too easy to change values in the worksheet to test different assumptions. And then lose track of all the changes made over time (version control)
The Presentation Readiness Problem: when creating spreadsheets, analysts (programmers) should anticipate their use in final presentations (user interface)
In summary, the author provides this sage admonition ...
Treat the development of a spreadsheet - any spreadsheet - more like writing a term paper with footnotes and a bibliography.
See that? Accountants and programmers should aspire to be ... students?
posted by James P. MacLennan at 3:37 PM
| Permalink
|
|
Monday, June 16, 2008
Data Visualization: 'Life' of Open Source Projects
Data Visualization: 'Life' of Open Source Projects
Part of the "art" of communicating IT and business abstractions - technicalchallenges, project roadmaps, budget performance, customer relationships, IT effectiveness - is landing on the right visualization. A picture tells a thousand words, and if you can draw the picture well, your target audience will grasp these concepts quickly, and (potentially) get insights that were otherwise difficult to attain.
I have a large backlog of web links to point to, posts to write that I'll probably start cutting into, now that I've seen this latest bit of visualization ... via Slashdot ...
A student at UC Davis has created some stunning visualizations of open source software contributions, including Eclipse, Python, Apache httpd and Postgres. From the website: "This visualization, called code_swarm, shows the history of commits in a software project. A commit happens when a developer makes changes to the code or documents and transfers them into the central project repository. Both developers and files are represented as moving elements. When a developer commits a file, it lights up and flies towards that developer. Files are colored according to their purpose, such as whether they are source code or a document. If files or developers have not been active for a while, they will fade away. A histogram at the bottom keeps a reminder of what has come before."
As a developer, I can draw connections between the narration of significant events and the "flow" of objects. I've used these tools/platforms for some time now, and the story told by the animation connects nicely with my understanding of these tools' "personalities" - gives some insight on how they "grew up".
Python: This one fits my understanding of a typical open source project; lots of work by one primary, maybe one or two secondary developers, with fits and starts, bursts of activity. Over a period of time, a limited number of additional authors contribute, and things slowly expand until critical mass is hit, and Python is released to the public. Then, a flurry of activity as the popularity takes off ...
Apache: I was fascinated to see this project start off as an exercise in documentation - and stay like that for the longest time (code doesn't appear until about a third of the way through the movie). Like Python, Apache is a focused platform/application, and had a fairly concentrated core of developers and modules - unlike ...
Eclipse: I watched this movie first, but it belongs last in the To-View list. Eclipse is a wide-ranging platform with a large number of modules/functions - and a correspondingly large number of developers. It's amazing to think that the overall project could maintain such a high-quality, unified vision.
posted by James P. MacLennan at 10:07 PM
| Permalink
|
|
Thursday, June 12, 2008
More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions)
More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions)
A recent post got a surprising amount of feedback - at least, different feedback than my other stuff. No flames, just folks agreeing with the ideas and wanting to engage in more direct conversation (phone calls, as opposed to blog comments or email - interesting ...)
I've noted that people like to second-guess and/or heap scorn upon their executive management team, seeing them as disconnected, clueless, and capable of speed without forethought. However, my experience tells me these attitudes are way out of line. Spend time in one-on-one meetings with them; listen when they ask probing questions during staff meetings, operational reviews, or any other meeting where they're going over details and weighing in with opinions. You can develop a much better understanding of where they're coming from if you attempt to walk a mile in their shoes - or just empathize a little bit.
These are common misperceptions that a typical organization has of the executive team ...
They Don't Make Decisions ... they just keep asking me for my opinion when I need them to make the call! Actually they're doing two things correctly; managing their time (because they can't micromanage the whole company) and empowering the organization (ie. giving you 1> credit for having half a brain, and 2> some leeway to make decisions). Remember, most organizations need problem solvers, not problem definers.
They Don't Consider All the Angles ... they skim the details and focus only on the big picture. People often make decisions without considering all the options and all the details; it’s a time management technique, relying on intuition backed by experience. It's just a tactic to help manage time, get on to the next thing - so don't take it personally. A better approach would be to give them the overview, let them know your decision for the go-forward approach - and then ask for feedback. If they disagree with your fundamental approach, I guarantee they will not be shy - they'll let you know right away. If you don't want them to make snap decisions that have huge impact, reduce their snap decisions to minor fine-points, and guide them where you want. If you really know your business and your audience, the executive input should be fine-tuning, not fundamentals.
They Resist IT / Technology ... the dinosaurs just don't get it! Truth is, they are much more technical than you think. I've had executives call out IT baloney about SQL queries, application response time, even e-mail attachments (I was told this attachment was too big to open - but later I was driving down the freeway at 80 miles an hour reading it on my Blackberry!). They don't need to understand the technology in gory detail, and you don't have to educate them on the nitty gritty - but they certainly need to understand how a given technology decision impacts total cost to implement, quality of the deliverables, speed-to-value, and ongoing cost to maintain.
They Aren't Paying Attention Well, not exactly. They will ask you to cut the details and get to the punch line, typically because they're thinking on a completely different level. You're probably worried about your departmental budget, annual performance goals, and/or resource constraints that put work for the next few weeks in jeopardy. They are thinking about making the month, making the quarter, and managing the owner's/shareholders' expectations for the next quarter or fiscal year. Also, they've got review sessions with engineering, marketing, operations, and finance - all scheduled between now and the end of the day. So, forgive them if they're not up to date on the differences between IE 7 and Firefox.
They Don't Understand the Problem Domain Actually, they typically have a deeper / more nuanced understanding of the business than most. They know (intuitively and factually) how to impact key numbers on the financials, and what levers to pull when they want to make a noticeable change. Questions that seem out of left field are actually efforts to make a connection between "why should I invest in this project?", and "how does this tie to one of my levers?".
Recognize that the executive team comes at the business from a different angle, and learn to listen to what is important to them - you'll raise your project success rate, demonstrate your value to the company - and maybe chill out a bit.
posted by James P. MacLennan at 11:24 PM
| Permalink
|
|
Thursday, June 05, 2008
Opportunistic Insights from the RSS Stream
Opportunistic Insights from the RSS Stream
I've written about using RSS for internal as well as external information sources. This past week, I found a couple of interesting tidbits in my feed reader (behind the firewall) ...
1. Eyes on the Skies: It's that time of year again; oil price volatility will continue if any big storms create problems for refineries in the Gulf - something new to keep an eye on. Never fear - our friends at NOAA kindly put out an RSS feed for storm details - here's the latest graphic on Tropical Storm Arthur, the first of the season. You can keep track of incoming storms using this RSS feed - at the very least, you can be first on your block to know the name of the next storm ...
Some of the responses to this original item pointed out the need to watch the tornado forecast as well put and potential impact on manufacturing plants and/or shipping lanes. There are many different ways that weather can impact the supply chain ...
New applications in the automotive and electronics sectors will drive the growth, although packaging will remain the dominant market. This is despite its share forecast to fall from 65% in 2007 to 40% in 2025.
I took this to mean that packaging is the dominant application of bioplastics, and will remain so. However, the future will see multiple other applications for this material emerge. More applications means larger markets, more innovation in the basic material - which is better for all plastics manufacturers.
3. From Rumor to Fact: One of the project managers recently added (1234) Project XYZ to our PMO database - I found out when the items popped up in my feed reader. That's how it's supposed to work ... Actually, my first reaction to the project was that the description (jpm note: we call it a "mini_charter") was a bit thin. But then I read the first comment, and there's definitely more meat there. At this time, Project XYZ is a multi-headed mystery monster - there are initiatives, teams, projects and such in multiple areas of the company. Clearly, more details to follow - but now we have a validated source of information for at least one of the BU's!
Show vs. Tell
These were my insights for the week, but a number of folks have told me of their own Aha! moments, watching project updates aggregate on their desktop via RSS. I suspect most folks reading this would think little of my "insights" - but that's because we understand how RSS works. To the rest of the world, websites are proactive (I have to go to them) while e-mail inboxes are reactive (the information comes to me). RSS and feed readers turn that paradigm around; once you see it in action, you get it immediately. But it's enough of a phase shift that sometimes explanations and PowerPoints aren't enough. Timely, relevant, in-context examples such as these just click.
posted by James P. MacLennan at 10:42 PM
| Permalink
|
|
Friday, May 30, 2008
Can you, should you, bother Executives with The Details?
Can you, should you, bother Executives with The Details?
In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He's talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for "owning" (vision, design, execution, and ongoing support). I've seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives that they are championing. It's a slightly different scenario than described in Jeffery's post - reporting status "up the chain" versus "to the customer" - but multiple nuances of "don't bother me with the details" come into play just the same. My only suggestion to Jeffery would be to exercise a little empathy and adjust the message. Management needs to understand the details in spite of their objections or shortcuts; the trick is to understand what's behind this drive for the quick answer, and adjust the communication accordingly.
Fractal Attention Span
Challenge: People typically work on 7-10 major items at any one time; that's about as many as the brain can comfortably prioritize for chunks of their attention. Unfortunately, these to-do items / projects are fractal in nature, easily decomposed into multiple tasks and subtasks. Our prototype CEO needs to deliver increased revenue (3 key accounts in play), reduced costs (2 cost cutting and 3 productivity-enhancing initiatives), while driving down inventory (S&OP, SKU reduction, and supply network optimization projects). Oh yes, there is also a pending lawsuit, product R&D reviews, and the board presentation to develop. The VP of Sales has five territory managers working on different aspects of the three key accounts, and two project managers working on the cost-cutting - in addition to ongoing promotional planning and customer service issues. Sally, the lead project manager on the first cost-cutting project, is working towards a launch date of 15 July, and has 10 open issues with varying degrees of severity.
If I'm the CEO, and I have two hours to complete an Operations Review for the entire company, I have maybe five minutes to listen to Sally tell me about her piece of the VPs piece of one of my 10 hot items; do I really have time to hear about usability issues or the challenges of scheduling acceptance testing? All I really need to hear is the specific objective of the project, current status, maybe the next milestone date, and our current expectations for meeting the stated objective (vs. budget and/or need-by date). Anything else and my eyes will glaze over, because I've got 20 other people to get through, backlogs in voicemail and e-mail, two more meetings before the end of the day - and I'd like to get home before midnight.
Mitigation: This environment is hostile to knowledge retention (ie. you risk the CEO spacing out), so you need to focus on the critical information. I (the CEO) need to hear a clear objective, a plan to get there, and an active monitoring process. I don't care about the options available or the decision process for task 4.2.6.a on your plan - I just need to know you are planning the work and working the plan.
"I don't believe you" might mean "I don't understand you"
Challenge: Phillips' post captures his frustration when project sponsors ignore input on usability and data access. Features and functionality are stressed over the intended audience's capability and willingness to use what is being built. Experience in creating and implementating software-enabled processes teaches you the impact of a poorly laid out web page, but this is experience that your project sponsor doesn't have. They assume all software is built consistently (look at Microsoft Word and Excel!), and that Google, Amazon.com, and YouTube are "user-friendly" solely because they're on the web (web = friendly and easy, right?).
Regardless, your [sample] project sponsor is very aware of one fact; their integrated demand forecasting system, driven from a single database for security, consistency, and speed, does not exist. I want to see project milestones that deliver what doesn't exist!
Mitigation: First and foremost they are correct. This new system we're building doesn't exist - that's why we're building it. So if you're talking to me about work that doesn't directly deliver the list of requirements, I don't understand why we are wasting our breath.
Here's the trick; to save your personal sanity and preserve your credibility, assume good intent. They aren't saying I don't believe you - they are saying I don't understand how this topic relates to my requirements. Of course, you must connect the dots between the need for usability [in this case] and the eventual delivery of the expected benefits. The system is only as good as the quality of the data going in.
This is important - when talking about issues, decisions, or work that needs to be completed, you most always tie back to stated benefits.
Nature Abhors a Vacuum
Challenge: Blithely ignoring the fact that the executive team has many other things on their plate (see above) our intrepid project manager lays out five major issues and three options for each one. I, as CEO, got to where I am by Being Decisive and Making the Call - so if you're giving me the options, I'm going to start telling you what to do because 1) you're asking and 2) I need to move on to the next agenda item.
Mitigation: Heed that classic management one-liner - don't come to me with problems, bring me solutions. We all get paid plenty of money to solve problems, and it really drives execs nuts when all we do is define tough problems - and look to them for guidance. Believe me, most organizations will massively empower you to show some leadership and make your own decisions!
Not to worry - there are many control mechanisms in place to guard against bad decisions, but you need to control the message and flow. When presenting to the execs, don't lay out options followed by your preferred choice - it sounds too much like you're asking for their choice, that the project is deadinthewater without their decision. A better method is to present your choice as the only way to proceed (this makes sense based on X and Y and Z). At this point, you can do a few quick bullets on the options, subtly giving the executive team an opportunity to ask probing questions and suggest alternatives. Trust me - if they have any issues, they will drill into these options and dissect your rationale. But when they don't ... progress!
The Myth of Executive Omnipotence
Challenge: In many companies, the executive team holds a magical sway. The staff adheres to their every whim; reworking this project "because the CFO said we should", reprioritizing that project down the list "because the CEO wants it that way". I love asking the "stupid" questions ... like Why does this need rework? What exactly does the CEO want to see as a deliverable from this team?. If you find yourself pondering (hmmm, I'm not sure exactly what he asked for, but he was pretty adamant - so we better deliver)
Mitigation: If your neighbor stops by to borrow a ladder or chat up the Fire game this weekend, you might have no idea that they are a COO or Vice President; she's just a regular person like you and me. So why would you grant them magical status in a workplace environment? Look, if you don't understand what they want, just ask for some clarification. You can make the [very safe] assumption that they are good men of business, and will react predictably to a business-based conversation. We had two options; here are the costs, benefits, and risks, and here's why were going to pick option one. If your assumptions differ from theirs, why can't you have an open conversation to challenge those assumptions?
Sometimes I think people are too self-conscious; no one wants to appear stupid and ask the General Manager to elaborate on what they're saying, because they aren't being very specific or they're making a logical or factual mistake. This is entirely possible, even probable - they may not understand the implications of what they're asking for, but since you the project manager, are defining problems not solutions, and since I've got 16 other things to do between now and quittin' time, I'll just start making decisions. I've seen plenty of projects get blown out of proportion and swerve down strange side routes because the executive said something, the team took it to be the One True Way To Go.
Update them on what they are expecting to hear about
Keep it to the relevant level of detail
present solutions to any problems that pop up
Anticipate some questions ...
... but don't offer up the details until asked
If you failed to write down what they asked for, follow up ASAP
... and figure out how to listen better next time!
posted by James P. MacLennan at 8:43 PM
| Permalink
|
|
Monday, May 26, 2008
Politically Correct Euphemisms in IT - Translated!
Politically Correct Euphemisms in IT - Translated!
I recently attended a professional seminar, and noticed a propensity for politically correct euphemisms to describe life in corporate IT. This was a typical group of IT professionals, representing a variety of companies - small and large, public and private. As with most group meetings, we started with a trip around the table; quick introductions, plus some highlights of "what's hot" for IT these days. The careful language wouldn't fool the experienced; however, a casual listener might see the knowing smiles on the nodding heads and think that we were either participating in a great conspiracy or dazed from too much coffee.
As I aspire on these pages to improve the quality of communication between IT and business, I feel duty bound to provide this partial translation page - what they say versus what they mean.
The project has been a challenge ...
We bit off way more than we could chew, and will probably blow the budget by 50%
We are considering ...
We talked about this one over beers, but there's no chance in heck of going forward ...
... looking at opportunities for SaaS ...
We're under budget pressure, and are desperate to say something to keep Finance off our backs about data center costs.
The database is growing rapidly ...
We massively underestimated growth rates, and are scrambling for capital to buy more disk.
The developer is quite aggressive ...
... they don't have time for documentation, debug in production and have polluted their workstation with multiple versions of component libraries that will cost millions to roll out
We did a pilot in CRM, and now we are comparing to salesforce.com.
The sales team played with it, realize they have to actually type data into the system, and now they're trying to delay as long as possible.
- alternative -
They asked for a shared contact database, we came with a $3M package implementation, and now we're scrambling to save face ...
... that's gonna stress us a bit ...
Another six months of nights and weekends? Good thing my resume is up-to-date ...
We have managed to create 18 instances of the ERP
The business can't make organizational decisions
- alternative -
Our development teams can't agree on a common QC cycle
- alternative -
We never had a long-term plan, this grew by evolution, and now we need a revolution
We've implemented (insert module name here) - which is ... interesting
This thing has more bugs than a VW convention in a swamp; we're in a first name basis with the core development team, and half the code has our IP in it.
... using the latest and greatest, and some we're still waiting on ...
The rep sold us vaporware, and we've already maxed his voicemail box demanding a delivery schedule (or a refund)
... after a lot of pain, discussion and analysis ...
we are on our fifth attempt at implementing, but the business sponsor can't cancel because he's overcommitted on the ROI
It's a legacy system, home grown, and its old.
We've gone through five lead developers, the original author is playing shuffleboard in Florida, and if the disk crashes we're hosed because we don't have the source.
This is going to drive quite a lot of work.
I'm stunned at how poorly thought out the project plan is ...
[ long list of acronyms and letters]
We are rabid technologists ... by the way, how come executive management doesn't invite me to meetings?
We're revisiting [something] (strategy, software package, implementation approach) after the acquisition ...
Awesome! We can cancel this screwed up project and restart it after the new owner settles in!
- alternative -
The new team runs a pretty tight ship ... good thing my resume is up-to-date ...
We're going through a process of stabilization before rollouts continue.
We hit too many walls and the business is fed up, so the project goes no further.
- alternative -
Another high priority project came along, and we got pushed down the to-do list.
The biggest challenge is the cultural shift.
Technical implementation is equivalent to C:INSTALL, but we'll be in training classes for months.
We experienced a little bit of a hiccup.
When the install dialog said "Are you sure?", I experienced a giddy sense of optimism that was quickly countered by a suitably horrible sound from within the drive ...
It's a learning opportunity ...
It's a chance to hone our skills at backpedaling, debugging on the fly, and byte-level disk sector editing.
We met our service level objective
Good thing we sandbagged the the target run rate.
... and this is what's going on ROW (Rest of World) ...
We don't like international travel, so our strategy stops at the border ...
... (refers to ) my soon-to-be partner (acquisition/joint venture) ...
... my soon-to-be subordinate, unless kick him out of his chair ...
- alternative -
Good thing my resume is up-to-date ...
Regional translations may vary; I invite your input on additions and variations ...
posted by James P. MacLennan at 12:33 PM
| Permalink
|
|
Wednesday, May 21, 2008
When is a project a Project? How to prevent the buildup of backlogged requests
When is a project a Project? How to prevent the buildup of backlogged requests
I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.
I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.
Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...
Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!
If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.
Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that littlesomethingextra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.
Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.
The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)
Ok, here's where we put the rest of these boxes, switches, wires, and other assorted doo dads in their place. Again, the witty reader will note that I am following along with Jeff Atwood's Build a PC posts from last summer, just adding some color commentary and my own personal notes.
Hard Drives, Optical Drives
When disassembling the case, I found one of the silicon grommets on the lower drive cage was a bit munged. Antec is great, they think of everything - the bag o' miscellaneous parts had a few spare ones.
Click on the picture for a full-size image!
The drive cages in the Antec P182 are pretty sharp. Those silicon grommets are an anti-vibration feature. It took me a bit to figure out exactly how to install the actual drives - this picture should help ...
Click on the picture for a full-size image!
Note that I put my start-up Raptor in the first position, and the 500GB Caviar in the third position. I had talked to some folks about doubling up and mirroring for security, and I may still do that in the future - just leaving space, seems like the decent thing to do.
I could have stayed consistent with the clean red SATA cables that came with the motherboard - but that blue cable from the Raptor box was just so cool looking ...
Miscellaneous
The P182 has USB and FireWire ports located up front - the cables for those are in the same bundle as the leads for the LEDS. The motherboard came with additional hardware to make these "visible" out of the back of the machine - more extra stuff to stash with the leftovers.
There's also a pair of wires for audio hookups - HD audio and AC'97. I found something on the motherboard for the HD Audio, but I'm drawing a blank on the AC'97 connector. I know it's high-quality audio for something ... ah well, a future project.
For optical drives, I took an idea from the Tom's Hardware walkthrough, and put in a pair of DVD-RWs.
Supplying power to the fans and drives is just a question of picking out the right one from the myriad spilling out of the Corsair. The real trick was hiding the cables and closing up the case - an adventure in folding. There are plenty of tie-up options built in to the Antec, which made the task easier - it's really a super case.
Final Thoughts
Well, now it's finally ready to go. As noted last time, I know it boots - now I just need to download the Ubuntu Hardy Heron CD ISO and get installing. But that's a different post - possibly. This blog is meant to be geared towards the application of technology to business, and vice versa - not a tech haven per se.
So what observations can I make as I survey the piles of spare parts and packing materials?
Evolution is a Powerful Force for Change: The advancements made in something as mundane as the case that holds it all still delight me. Slide out drive cages, anti-vibration and noise reduction all over the place, and spaces to make cable management easier. If you haven't looked at the guts of these machines lately, you will find that the "state of the art" never stopped innovating and improving.
Standards-Based Hardware: Making the "Case" for Standards-Based Software? Ever since the days of the XT clones, these machines have been designed for interoperability with different parts manufacturers. Still, the wide variety of vendors, coupled with the degree of fit for all of these components - makes a strong value statement for available and accepted standards. When all manufacturers agree on the base requirements, and differentiate based on features, functionality, and price (all together), the result is higher-capability machines for a very reasonable price. Makes you want to do the same with all of the systems getting designed and built at work ...
For starters, I give major props to Jeff Atwood's series on building a PC, because the step-by-step assembly notes, and the overriding "calm down, it's like Legos!" tone ... all very comforting. I tend to be a "ready, fire, aim" kinda guy on my home technology projects, so a little common sense around the electrical equipment is always good.
I won't replicate all of his build-in-process steps or pictures, just the highlights. One thing you will need is a decent work space - don't try to build this on the floor of your den/home office.
The only tools I needed were a Phillips screwdriver and a little knife - lotsa packages to open!
Check Out The Case
I was amazed by the heft of the P182 - it felt like a loaded PC, not an empty shell. Can't wait to hoist it around when it's full of components ...
Some extra work: a nice note from the manufacturer reported a chance that the fans misbehaved at low speeds. This was a defect they couldn't catch until after assembly, so they threw three extra fans into the box, just in case. I didn't want to mess with it later, so I swapped out two of the three - one was too difficult to get at, I'll just take my chances. Plus, now I have three spares (more junk for the closet).
Before you start adding components to the motherboard, dig out the back panel and "dry fit" the motherboard and back panel into the case. This wasn't entirely plug and go, I had to fiddle around with the various tabs and knockouts to get it to come together. Take the motherboard back out, now we've got some tabletop work to do.
Building Up the Motherboard
The memory sticks were bigger than I anticipated - and yes, I double checked, it's physically impossible to put them in backwards
Slip the processor into the slot on the motherboard per the directions - very simple stuff.
The processor (CPU) is dwarfed by the cooling fan (Standard CPU Fan) that comes with it ... but that's not a real cooling system ...
... I was genuinely flabbergasted by the size of the IFX-14 CPU cooler (Main Heatsink). The picture below sizes it all up, next to some real world objects you may be more familiar with. In retrospect, I'm not entirely sure I needed the aftermarket CPU cooling system, but I appreciate the heat problem inherent in these types of machines, so I'll just play along.
Click on the picture for a full-size image!
Consider going through the entire heat sink installation "dry" - it involves sticky pads, screws and posts, and thermal paste (!). The instructions are capable, but not entirely idiot proof. The dry run is important, because we've now come to ...
OOPS #1 - The IFX-14 CPU cooler also comes with the IFX-10 backside motherboard cooler (Backboard Heatsink) - nice additional cooling, I suppose, but as I went through the dry fit to check how things line up in the case ... erp, nope, the IFX-10 sticks out too far. Some geeky desktop jewelry, I suppose, but the big tower fit just fine, so the IFx-10 is out, and on we go.
Another gotcha - attaching the fan. Slightly tricky, and the installation illustrations (which had been excellent to this point) left me with a puzzle. I finally figured it out, so here's a pic to show exactly how to thread those wires (fan clips) through the holes. I've also called out the proper orientation of the anti-vibe strips - also, not called out well in the installation instructions.
Click on the picture for a full-size image!
Two bits of hindsight, for your benefit:
Now that you've got the fan attached - take it back off. You'll see why in a minute.
Some system fans have a speed sensor for control - and the motherboard may have a specific power connector for that fan. Find it before you screw everything in place - might be hidden underneath Gigantor-sink.
Back to the Case
The power supply fit is tighter than tight - aided by the anti-vibration strips inside the cage, I am sure. For this step, you will need to take both sides of the case off.
Leave all of the power cables trailing out the nearest side of the case. As we install components, we'll want to be crafty in how we thread the cables, to keep the interior as nice and clean (and maintainable, and expandable) as possible.
Finally - in goes the motherboard. It's easiest to get in there with the case lying in it's side, but now I've got multiple power cables hanging out back there, so I'll just have to make do.
The case came with a bag full of a wide variety of screws, and no pictures in the documentation - but the bag-within-a-bag, labled MB Only, was helpful. Put as many mounting screws in as you can reach - that heatsink gets in the way of one or two.
Power supply to the motherboard - two cables! You'll be able to hide most of these cables under the motherboard - snake them up through the available openings.
OOPS #2 - This is where I had to (temporarily) remove the fan. The CPU power supply (cable #2 for the motherboard) "conveniently" plugs in right below the heat sink fan. I got it all to fit, but man, I'm really starting to rethink this whole aftermarket CPU cooler idea. Note that this is no slouch against the performance of the device; it was rated best by Tom's Hardware - but it definitely is a tight fit.
Click on the picture for a full-size image!
They're at the Post!
Why yes, I _am_ following Atwood, step by step. Trying hard not to duplicate his pictures, but augmenting his play by play with mine. Here's the final turn for today ...
Install the video card. I'm keeping it simple, with a single GeForce 8600 GTS - supports dual monitors, which I dig, but I am not the hard core gamer.
