Posts Tagged‘project’

Lockheed Martin Promises Fusion in 5 Years.

There’s little question in my mind that the future of energy production on earth lies within fusion. There’s simply no other kind of energy source that can produce energy on the same scale, nor over the extended periods of time that it can. Of course the problem is that fusion, especially the net energy positive kind, is an incredibly hard thing to achieve. So much so that in the numerous decades so far no one has yet made a device capable of producing sustained power output and the one project that might, ITER, is decades behind schedule. Thus you can imagine my scepticism when I hear that Lockheed Martin expects to have a device operable in 10 years with it being widely available in 20 (snicker).

Lockheed Martin Compact Fusion Reactor

The Compact Fusion project comes out of Lockheed Martin’s Skunk Works labs which have delivered such things as the venerable SR-71 in the past. They’re a highly secretive bunch of people which is why this announcement, along with a rather well designed website, has attracted quite a bit of interest as typically any project of theirs that might not deliver won’t see the light of day. Thus you’d assume that Lockheed Martin has some level of confidence in the project, especially when they’re committing to delivering the first round of these devices to the military in the not too distant future. Indeed if their timelines are to be believed they could even beat ITER to the punch which would be a massive coup if they pulled it off.

Their design has the entire reactor fitting on the back of a truck (although the size of said truck is debatable it looks to be the size of a tanker) which is an order of magnitude smaller than all other commercial fusion reactor designs. This is somewhat perplexing as the style of containment they’re going for, the tokamak style which ITER uses, scales up quickly (in terms of power) with increased plasma volume. There are limits to this of course but it also means that the 100MW figure they’re quoting, which is 20% of what ITER will produce, comes with its own set of problems which I don’t believe have good solutions yet.

Indeed whilst the project will be standing on the shoulders of numerous giants that have come before them there’s still a lot of fundamental challenges standing between them and a working reactor 5 years down the line. However should they be able to achieve that goal it will be the start of a new age of humanity, one where even our wildest energy demands could be met with the use of these clean running fusion reactors. The possibilities that something like this would open up would be immense however the the long running joke that fusion is always 20 years away still rings true with Lockheed Martin’s compact reactor project. I would love for my scepticism to be proven wrong on this as a fusion powered future is something humanity desperately needs but it’s always been just out of our reach and I’m afraid it will continue to be for a least a while longer.

How I Killed My University Project.

It’s the beginning of 2006 and the end is in sight for my university career. It’s been a crazy 3 years up until this point having experienced both the dizzying highs of excelling in a subject and the punishing lows of failing to understand even the basic concepts of some units properly. Still I haven’t failed a single subject (despite some near misses) and really the only thing standing between me and that piece of paper I’ve been chasing is my final year, most of which will be dedicated to working on an engineering project. I had been looking forward to this for a while as I felt it would be a chance to test my meddle as a project manager and hopefully create something valuable in the process.

The year started off well as I found myself in a project team of 4 including 2 long time friends and a new acquaintance who was exceptionally skilled. After brainstorming ideas we eventually settled on creating a media PC with a custom interface based off the open source MythTV project which would handle most of the back end work for us. After getting a space to work in we covered the whiteboard in dozens of innovative ideas ranging from TiVO like recording features to remoteless operation based on tracking a user’s movement. Looking at the list we were convinced that even that list of features wouldn’t be enough to fill a year worth of development effort but thought it was best to settle on these first before trying to make more work for ourselves. With the features in mind I set about creating a schedule and we set about our work.

Initially everything was going great, we were making quite a lot of progress and the project was shaping up to be one of the best of the year. The hardware design and implementation was looking phenomenal, so much so that I made the brash move of saying there was a potential market for a mass produced version of the device. Our lecturers showed a keen interest in it and we even managed to come in second place for a presentation competition amongst all the project students, narrowly losing out to an autonomous robot that could map out and navigate its surroundings. We were definitely onto a winner with this idea.

However my desire to project manage 3 other people started to take its toll on the project. Realistically in a team of 4 everyone needs to pitch in to make sure stuff gets done, there’s really no room for designated roles. I however kept myself at arms length from any solid development work, instead trying to control the process and demanding vast reams of documentation from those doing the work. Additionally I failed to realize that the majority of the coding work was be done by a single team member which meant that only they understood it, making collaboration on it next to impossible. Seeing the beginnings of a sinking ship I called everyone together to try and figure things out, and that’s when things really started to turn sour.

The primary coder expressed their concerns that no one else was doing any work and I, still not realizing that I didn’t need to be a project manager, instructed them to take a week off so the others could get up to speed. This didn’t work as well as I planned as they continued to do all the work themselves, effectively locking anyone else out from being able to contribute to the effort. I did manage to get the star developer to collaborate with the others but by this point it was already too late as they’d usually have to rewrite any code that wasn’t their own.

In order to save some face in this whole project I elected to do the project report entirely on my own, realistically a task that needed to be done by all of us (just like the project). I spent countless hours cobbling everything together, piecing random bits of documentation and notes together into something resembling a professional report. It wasn’t amazing but it was enough to get the approval of everyone else in the team and our project co-ordinator so a week before the final demonstration I handed it in, wanting to be done with this project once and for all.

The final demonstration was no picnic either with everyone in the team (bar me) staying at university until midnight before the presentation. We managed to demonstrate a much cut down version of our initial vision to the class with only a few minor hiccups and the 2 honors side projects went along quite well. Afterwards we hurriedly bundled the project away into one of the members car (he provided all the hardware on the proviso he got to keep it) happy to be done with it once and for all.

For 2 years afterwards I struggled to figure out why the project that started off so well tanked so badly. It wasn’t until I was officially employed as a project manager that I figured out that the most toxic element in the whole ordeal was me, the power hungry idiot who contributed the least whilst ensuring that anyone trying to get things done was hampered by my interference. I failed to get everyone to collaborate effectively and hamstrung them with rediculous requirements for documentation. In essence I was acting like a project manager on a big project when really I was anything but. The end result was a far cry from what it could have been and one member of that project team still refuses to speak to me, and I don’t blame them for doing so.

I suppose the best thing that came out of this is that I finally realized my weaknesses and actively worked to overcome them. Sure it might have been too late for the university project that was but I’m glad to say I didn’t inflict any such torment on a project whilst I was being paid to do it, instead taking on board those lessons learned to make sure those projects were delivered as required. I still hold out hope that one day I’ll look back on those days with my former project members and laugh but those project management war wounds will stick with me forever, reminding me that I’m not as infallible as I once thought I was.

Managers, Metrics and Misanthropy.

When I was a young and naive lad I had firmly set my sights on becoming a project manager. It seemed like a great place to aim towards, the money appeared to be good and you’re not bound to one industry so there’s no end of jobs and new opportunities. I even managed to convince two groups of university students to make me their project manager, with one of them garnering a mild success with the other failing horribly (which I will admit was pretty much all my fault). Still this didn’t deter me and I continued to pursue a career as a project manager, working my way up from low level IT work in the hopes I could make the jump into projects sometime in the future.

Roll forward a couple years and I found myself working for Unisys as part of the outsourcing arrangement with the Department of Immigration and Citizenship here in Canberra. It was a good work environment and I quickly improved my skills over the first 6 months or so. I even thought I had the skills to take a shot at one of the specialist positions, something that I hoped would lead me onto more project work. Talking to the current specialists I was led to believe it was a very client facing position, and I marketed myself as someone who was capable of managing client relationships well and proving to be a valuable project resources. I didn’t get the position however they did offer me a role as a technical lead in the new projects section they were creating, something which sounded pretty cool at the time. Eventually it turned out that this position was really a junior project manager role, and for the first time in a long while I was put in charge of projects. I was in for an awakening of sorts, since the corporate world was nothing like the academic.

My first few months in the position started off well. Our section consisted of 2 other people who were in positions just like me. Our focus was small projects that wouldn’t require the involvement of the solutions architect and could be resourced internally. Most of these were IT projects that weren’t covered in the out-sourcing contract, something which I’ve blogged about previously. We were basically a pure profit centre since all of us were hired as system administrators (fully paid for by DIAC) and were moved to the projects team due to them being able meet SLAs without us. I got to work on some pretty cool projects there with my favourite being the deployment of digital fingerprint scanners and cameras to the detention centres in Australia. The house of cards started to come tumbling down when the higher ups needed a “clearer view” of what we were doing and of course bungled the whole thing.

Since we had come from the administrators team we still used the majority of their systems for all of our daily activities. Requests for new projects would come through the same incident management system and this was the first place management decided to look for to derive some metrics. The problem here was that a typical project can’t be judged under the same SLA as an incident, since one of them is a problem that needs to be resolved ASAP and the other could stretch out over many months depending on the scope. We copped a fair beating over the way the tickets were being handled, so we fought back saying the system was inadequate for accurately tracking our progress. This led to a lengthy battle between us and the Projects Management Office (which at the time was technically the Asset Management area) as they had promised us as system that would allow them to get the metrics they desired. We eventually got our way by not going through the “proper channels” (we called a meeting with them directly without involving our managers) and got a system in place. This happened a few weeks before I left Unisys, and was still suffering from teething problems when I left.

My short time as a project manager taught me many things. The first was that I never wanted to be a project manager ever again. Most of my time was spent either chasing clients for money or asking them whether or not they actually wanted the project they asked for. Also project managers should never be taken from a group of people they will be managing as they need to be at least 1 step removed to avoid any contention issues. There’s nothing more awkward than trying to force your friends or former colleagues to do some work, something I encountered a few times.

The second, and probable one of the most valuable lessons, was that you have to be careful in how you define and apply metrics to anything as improper use of them will skew your vision of what is really happening. One of the often use metrics that I despise is the time taken to close a call when on a help desk. The poor operators were pressured into closing their calls quickly which usually meant that if the problem wasn’t solved there would be a severe lack of information, transferring the load from the call centre to the more costly second level support teams. Closing calls quickly is great and all, but what they what they were really doing is costing the company more to get the same outcome.

It was all summed up pretty succinctly for me in this one quote I came across on Slashdot:

Management gets the behaviour that it rewards, not necessarily the behaviour that it pretends to ask for.

Metrics are supposed to encourage people to achieve goals that align with the company’s vision. However they more often than not reward people for doing something completely different and that’s where the problem lies. I guess it all comes from that culture of wanting to boil everything down to a nice chart for the higher ups, but that’s a story for another day.