Archive

Author Archive

Blue Screen when Installing Windows XP: Stop Error 0×0000007B

June 11th, 2010 admin No comments

I’ve recently needed to reformat a Windows Vista (Home Premium) machine, and I was trying to load Windows XP Service Pack 2 on it. It kept on blue screening with the STOP error 0×0000007b. I did some research and it seems that it may have something to do with XP not communicating properly with the storage device.

If you go into your BIOS and find the settings for storage devices, change it from “Auto/AHCI” to “Auto/ATA” and you should be good to go. I did this and XP installed perfectly without a problem.

Leading a Highly Effective Team

June 9th, 2010 admin No comments

There are many traits that make up a good team but the three I think are most important are commitment, appreciation, and communication.

When everyone on a team is committed, the team works much more efficiently. Each team member is happy and knows the other members have their back. Every member will ideally be committed to the team and to each other team member individually. This doesn’t necessarily mean that team members will be conflict free, but they won’t let their personal conflicts interfere with the team’s goals.

Appreciation helps team members stay committed to the project/operational group. Letting the members know that they are appreciated and they are truly valued. It also helps increase general feelings of goodwill. Showing appreciation is as simple as saying “You did a good job when…” or “I liked the presentation when you were talking about…”. Appreciation helps keep the team focused on their wins, not on each others faults.

Communication is another big must for teams. Without effective communication, team members will become distant and isolated from each other, thus negating any benefits of forming the team in the first place. Maintaining effective communication can be as simple as holding a short weekly meeting to discuss deliverables, or as informal as building rapport with the members.

It’s important to remember that trying to maintain ridged communication lines can sometimes backfire. As a leader, you may try to increase communication by having a weekly meeting, but if the team feels that the meetings are too long, or if certain members monopolize the time, team members can quickly become demoralized and your efforts can backfire.

Office 2007 Document Downloads as Zip File in Internet Explorer (MIME Error)

March 25th, 2010 admin No comments

I recently had an issue where a Word 2007 document (.docx) was on a shared server but users were unable to download it correctly. I tested it in Chrome and Firefox (yeah, you can tell I’m a computer guy) with no problem. The next day other users were complaining of the same issue, so I fired up Internet Explorer, tried to download the form and it was popping up as a .zip.

After some research, it appears Internet Explorer tries to determine the file type from the MIME type the server responds with. (I actually prefer it this way as opposed to looking at the file extension, but that’s another matter.) I can only assume that there was no associated MIME type in Apache for the file so good old IE figure’s it’s a zip file due either to the server using compressed HTTP or the fact that the open xml documents are compressed.

Either way, adding a .htaccess file with the correct MIME types solved my problem. Here’s what I added below:

AddType  application/vnd.openxmlformats  .docx .pptx .xlsx .xltx . xltm .dotx .potx .ppsx

Just throw that in a file called htaccess.txt (assuming you’re in Windows), upload it to your server, and rename it to “.htaccess”. You should instantly be able to download the file.

EDIT: Just as a side note, I thought it was funny when I called the hosting company to let them know of their oversight, the tech on the other end of the line told me it wasn’t an error, tried to tell me that Chrome used the IE rendering engine, and that Opera was actually a new web browser. Very amusing.

Integrated Change Management Should Change the Way You Manage Your Projects

March 25th, 2010 admin No comments

Integrated change control procedures are made to allow for consistent change control from project to project. This allows for the same change control protocols to created once, and used between projects.

Change control procedures should be used in every project because they provide a constant method of change metrics as well as reduce the time in the project initiation phase. The main difference between the details of a change control plan and integrated change control is that integrated change control requires management approval from higher in the organization chart due to the need to assess the impact to other projects as well as the project that needs the change.

Larger organizations probably benefit the most from integrated project control because of the rate of turnover. The change in personnel demands a greater need for consistency.

Types of Project Estimates

March 11th, 2010 admin No comments

There are a few different ways to estimate in projects but a general rule of thumb is to use the most accurate method available. There’s the rough order of magnitude, top down, budget/engineering.

Rough Order of Magnitude
This type of estimate is of a top level conceptual nature. It is generally used when not many details are known about the phase/sub-project and a numeric cost must be given to the segment. It’s accuracy is between -25% to +75%.

Top Down
The top down estimate is a mid level estimate. It’s used when more details are known and it’s possible to actually begin budgeting for the project. It can be used in the proposal/contractual stages. It’s accuracy is between -15% to +25%.

Budget/Engineering
This is a work package level estimate. It’s possible to provide this level of estimating when you know most if not all of the details involved and is based on the consumption of real effort and resources. It has the best accuracy of all three types of cost estimates, and is generally accurate between -%% to 10%.

Common Cost Categories in Project Cost Estimation

March 11th, 2010 admin No comments

Accurately estimating future costs of a project is crucial in the project planning phase because it helps accurately predict a project’s benefit. In my experience there are three major common cost categories:

  • Fixed Costs
  • Variable Costs
  • Operating and Maintenance Costs

Fixed Costs
Fixed costs are costs that do not vary with the output of production. For example, if a software firm spent $250,000 on the development of an iPhone application, the number of sales does not increase or decrease the cost of production. In a case like this, it’s important to have as accurate as possible sales forecasts to make sure that the project is worth-while.

Another example is the cost of R&D it takes a car manufacturer to develop a new brand of car. The company has to pay designers, engineers, marketers, hire sub-contractors to develop new parts, ect. that goes in to each car. This is is a cost that doesn’t change based on the number of units sold.

Variable Costs
On the other hand, variable costs are costs that have a direct correlation with the units produced. The same iPhone software company may need to pay for hosting or bandwidth for their users to use the application. Each user of their application will consume some server storage space or bandwidth that the company is providing, thus they pay more for it. The more users the company has, the greater their expenses.

In the case of the car manufacturer, once designed, they have to pay for each part that goes into the car. Each screw, seat, and light bulb increases the cost of the car, but if they didn’t sell any cars, they wouldn’t  need to purchase those items. Those expenses increase when units of production increases.

Operating and Maintenance Costs
Although not completely project related, operating and maintenance costs factor in to the project approval decision because management must know how much it will cost to keep the project’s outcome operating in the future after the project has been completed.

Don't Set it and Forget It: Update Your Project Schedules Throughout Your Projects

March 3rd, 2010 admin No comments

While reading Project Scheduling and Cost Control, by James Taylor, one thing that stuck out for me was how it is critical to update a project’s schedule no matter what type of network diagram or chart you decide to employ. It never really struck me as an issue because I haven’t worked on “huge” time consuming projects, and if I have, I was normally the only resource available for the project so everything was done fairly sequentially.

When managing larger projects, I can see how tasks may be finished earlier than expected or later. Without keeping track of when these dates change, you won’t be able to accurately schedule the following tasks. It would also make crashing the project much harder because you wouldn’t know the status of all of your tasks and if they are complete or not so you wouldn’t know how much time you could save, if any.

Many projects have financial implications tied to the due dates. For example, a company may get a $1.5M bonus for finishing an electric plant 6 months early, or they may be penalized and legally responsible for any lost profits for not finishing a refinery on time. Being able to tell the status of a project and each of it’s tasks is vital in knowing the overall health and agenda of a project. One easy visual way to keep track of such information is by using a Gantt chart which presents massive amounts of data in a simple, easy to read chart.

Let Me Break it Down for You: Work Breakdown Structures

March 3rd, 2010 admin No comments

Work breakdown structures are extremely useful way to simplify complex tasks that need to be accomplished in a project by their individual components. They can also be combined with scheduling data to generate a Gantt chart (the end result is something similar to the Microsoft Project interface). The United States Department of Energy’s official definition of a work breakdown structure (WBS) is a product-oriented grouping of project elements that organizes and defines the total scope of a project.

One of the most important (and for some reason then-perplexing) lessons I learned in my undergraduate project management class was the fact that when developing a WBS, you cannot breakdown an element into only one sub task. For example, if you have a project that was cooking dinner, and one task was to take the food out of the oven, you can’t have the only subtask be “remove tray from oven”. You would need to break down the task into more than one step, otherwise you’re either reiterating the task itself, or you haven’t fully broken the task down.

I’ve used work breakdown structures extensively in personal programming projects. I personally follow the agile project development paradigm which is very suited to software development that is very features based and can be fluid (I personally would never try to build a bridge using agile project management methods, but then again I’d never try to build a bridge either!). When I develop a WBS, I first define the goals or features that I want in the next iteration of the software. That list generally makes up my root tasks on the WBS. I then subdivide each one into tasks I need to accomplish to have each feature complete. I then take a look at all of the tasks to see if it’s logical to break any down further. Normally I do this if I need to wait on someone else for part of a task, but I can complete another part by myself. If I can complete all of a task in a reasonably short period of time then I’ll just leave it without breaking the task down.

I personally like using Microsoft Project’s implementation of work breakdown structures. It’s very logical and is integrated with a Gantt chart. I also use some software called Trac to develop a WBS type of structure. It breaks down software development into Milestones (also called releases) and lets you add features to teach release. Using agile development, I like to have a two week dev cycle, normally with 1-1.5 weeks on development, and the rest on bug fixes and testing.

“DOE Environmental Management (EM) Glossary of Terms”. United States Department of Energy. 3/3/2010 <http://www.em.doe.gov/pages/PBSGlossary.aspx>.

Green Tech: A Hard Road to Hoe

February 23rd, 2010 admin No comments

Fred Engel is a technology entrepreneur that has sold a business and taken another public. He’s currently starting a new green technology venture that centers itself around reclaiming lost energy efficiencies in commercial building’s HVAC systems. His systems analyze feedback from the building automation systems using software to help building owners achieve cost savings through reduced energy consumption.

In order to analyze this opportunity without the financials one tool to use is a SWOT analysis:

Strengths

  • Venture has the appeal of “green” technology which is in season these days
  • Venture backs the green fad with actual cost savings
  • Venture has an elite team with a concept that has a large market and good potential
  • Management team listens to feedback and is still agile enough to make changes to core product/service

Weaknesses

  • Sounds like venture capitalists are reluctant about the idea in it’s current state
  • Green is a fad which may harm the company’s image in the future
  • The company may run into a cash flow problem if they cannot find funding

Opportunities

  • Large market for their services
  • Potential to be published and gain market awareness through white papers/presentations to be known as the industry leaders
  • Venture can lobby to get energy reduction laws passed to force a market for their services

Threats

  • Companies may not realize the savings that can be had and only see the cost of Engel’s solution
  • Running out of cash may mean the end of a potentially profitable organization
  • Companies may force their current HVAC maintenance crews to achieve the efficiencies that Engel’s software can provide

All things considered, with Engel’s background and his experience in not only developing successful organizations, but his ability to take feedback and turn it into actionable steps, his venture will be a success. The movement towards clean energy will only help so much, but his focus on cost-savings as energy costs rise will help him gain traction in an otherwise controversial market.

Personal Experience with Project Scope Statements

February 22nd, 2010 admin No comments

I used to work at MD Anderson Cancer Center where I developed web applications. Part of my job was to directly interface with customers and take their requirements and develop them into finished products. Our team of developers each had their own projects to work on, and could decide if they wanted to interface with the clients or if they wanted the project manager to be the intermediary.

I decided to manage my own projects so I could understand the clients needs directly and so I could bring up ideas or technical issues that the clients may not have known. Talking with the stakeholders directly made developing the scope statement very easy because I could take their needs, formally write them up, and document what the project was.

A scope statement is a very necessary part of a successful project. While working on a project that I inherited from the titled project manager, I developed an application to the specs that he verbally told me. He later got a promotion and when I started talking with the stakeholders, 80% of the features I had developed were “cool” features that were functional, but did not meet the needs of the clients. If I had a document to work from that was signed off on, there would not have been any surprises and there would be accountability for project failures.

I believe the old project manager had a philosophy of “passing the buck”. I had asked him a few times to send me requests via email, or to get some paperwork signed by the stakeholders so there would be no surprises, but he wanted to not be accountable if the deliverables weren’t done by a certain date. This is a completely inappropriate attitude for a project manager. First, if the deliverable isn’t completed on schedule, it’s the developer’s fault, not the project manager’s. Second, the goal of a project is to provide a benefit for a business and taking it to such a personal level undermines the business’ best interest.