Some of the things I intend to write about in the upcoming months:

• What's Being Developed – Despite increased attention to blogging, I'm still developing my first title. I'll be writing about all the hair-pulling, desk-smashing and tea drinking that comes with the territory.
• Game Design Lessons – This will be a regular set of articles examining games, and discussing what design can be learnt from them.
• Development Tips – Tips on indie game development, with a focus on methodologies that can be used to increase developer productivity.
• Handy Tools – A look at tools that help with the painful aspects of game development.

Here's a few links to some of the best stuff that's been written on this blog:

• Keeping a Progress Log – A look at the system I use for tracking my goals and progress, which was inspired by David Seah's Printable CEO.
• 30 Days of Positive Affirmations – A small series of articles I wrote whilst I was experimenting with positive affirmations.
• How to Ensure Your Project Fails – Sure-fire strategies for making sure your software project ends up in the fiery depths of development hell.
• Turn hotlinks into advertising – Tired of people stealing your images? Turn an annoyance into a potential source of income using a few server-side tricks.

You can subscribe to the blog using the RSS feed provided, so you'll always know when new articles are added.

When I first started this blog last year, I'd originally intended it to be more geared towards game development and software. However, it turned more into a personal blog about productivity. Although I've not exactly written a huge amount, I realised I'd like to dedicate more time to this area, and I don't think the Sodaware blog is the right place for it.

I'll be changing the appearance of the blog so it matches the rest of the site, and changing the content to make it more game development oriented. The personal development side of things will be moving to a new website, which will be more focused on the topic.

The best posts from here will be added to the new site, but will remain here so as not to break existing links.

The new design will go live on Monday 12th June, and the new site will be released at the same time. I hope you'll stick around and see what happens!

Probably the biggest problem I had was getting the thing installed. Installing the Professional Suite took quite a long time, and I had to fiddle around to get everything working properly. Outlook in particular was a pain, because the installer didn't uninstall the previous version despite me selecting the option. None of the problems I encountered were catastrophic, but they all added up to make me quite annoyed.

The other main problem I've had is with Windows Desktop Search. I've had no luck getting it to work, so I've decided to give it a miss. I'm a bit annoyed that Outlook requires it for the Instant Search, but search folders still work so I can live without it for now.

I've not had time to give everything a thorough going over, so I'll stick to what I've spent the most time with.

Unfortunately I've not had a great experience with OneNote so far, but I'm putting it down to a hardware / driver problem on my machine. The mouse has a habit of jumping around the screen, and then the app crashes. This has happened to me with other apps, so I'm not blaming OneNote. It's a shame though because it looks like a really cool app.

When it has worked, I've had chance to play with copying text from images and jotting down notes about various subjects. I have a feeling it would be a great tool for organising blog posts, so I'll definitely be giving it another shot when I get a new computer.

The first thing you notice with Excel is the Ribbon. Seeing as it's in a few apps, I'll talk about it in detail later, but for Excel it really makes you feel like you're getting more. You can see a lot more functionality without digging around too much, and the new tooltips explain features a lot better.

I mostly use Excel for scheduling time on projects, so I haven't seen most of what the product has to offer. I'm sure I'll have a better idea of what it can do over the coming weeks, but for now it does it's job and that's all I can ask.

I use Outlook every day, so I was a little anxious about replacing the original with the Beta. It's been a mixed bag so far, and I'm not completely convinced.

The new To-Do bar is a nice addition, and it gives you a good overview of upcoming tasks and appointments. I've found it much more useful than "Outlook Today".

There seem to be a few tweaks email wise. You can quickly assign a category to emails, and flagged emails show up in the To-Do bar. The task and calendar sections have also been improved. None of the improvements really stand out yet, but they all add up to a more pleasant, tighter experience.

Performance wise, I'm a little disappointed. I don't exactly have a powerhouse of a PC, but for me Outlook is the most sluggish of all the new Office tools. It freezes for a few seconds whilst switching emails, and can freeze for quite a long time for no apparent reason.

The interface for composing emails benefits from the new Ribbon, but it's not so useful if you're a fan of sending plain text emails. If you want to get a little fancy though, it looks like it will be a big help.

The first thing that really struck me about the new Word is that it looks, well, nice. I realise it's only a word processor, and that looks are secondary to functionality, but it's always nice to enjoy using a piece of software. My first impressions were definitely positive.

Of all the programs out of the new Office that I've used, Word certainly feels the most improved. It's still a little bit ropey in places however, particularly in some of the older dialog boxes. The overall experience is very slick though, and I've found that the new appearance and interface alone makes me feel more productive.

Styling the document is a breeze, and the “live preview” feature is more useful than I imagined it would be. Simply hovering over styles in the gallery will change the selected text. This is nice because you can see how the style will look without having to worry about ruining the document if you don't like it.

Not all the improvements are as big as the ribbon. The status bar at the bottom lets you change the view and zoom level quickly, and also displays the current word count. Nothing spectacular, but it's a welcome improvement.

It's not all good though, and one feature I was disappointed with was the blogging support. From what I gather it was only recently added, but as it stands it's not very useful at all. It can't use categories in WordPress, and it also gives the wrong posting date. Oh dear. Here's hoping it will be much improved before the final release.

I'll be honest, I've never been as interested in any of Microsoft's products as I am about Office 2007. Public betas, blogs such as Jensen Harris's and a fresh interface really seem to have moved the product forward.

The Ribbon isn't as obtrusive as it may look, and it can be collapsed to give even more space to the document. It didn't really take any getting used to, and I have a feeling that once you've used it for a few days you won't want to go back to the land of toolbars.

The biggest complaint I have is the lack of consistency in usability. The Ribbon makes using most features much, much easier, but it's a shame that there are still poorly designed dialogs present.

I realise I haven't dug too deep into the products, but for general use they've been a pleasure to use. Word is certainly a big improvement, and I don't think I'll be switching back to Office 2003 any time soon.

There are plenty of ways that a project can be considered a failure. Some are more subtle than others, and may depend on the kind of software being developed and the individuals involved. Common types of project failure are:

• Over budget – The project is finished, possibly before the deadline, but cost much more than expected. This may not be such a big problem for large companies, but for a small business with a tight budget, it can be disastrous.
• Late delivery – The project is finished, but this time it is later than initially promised. Again, this may not be a fatal problem for a big company. For some people though, it can be so bad that a day late is a day without food on the table.
• Lack of promised or essential features – If you promise your software will do something and it doesn't, then that's a pretty big problem. This type of failure may be a symptom of trying to avoid either (or both) of the problems above.
• It's not what the client wanted – Similar to the above, although it's more likely to be caused by bad specifications than by poor scheduling.
• It doesn't sell – This is another type of failure that can kill an indie developer. Failure to sell can be the result of poor market research, a lack of marketing or a plain sucky product.
• It's cancelled – This one is pretty obvious. A cancelled project can be a sign of any number of symptoms, from bad management to a lack of resources.

Now we know the types of failure, let's see what we need to do to achieve them!

There are plenty of things you can do before the project starts to make sure that it never succeeds.

• Ignore client requests – If you're working directly for a client, make sure you ignore what they ask for. After all, you're the one who knows how to create software, right? You can score bonus points here by mocking them, pretending to listen whilst doodling, or blinding them with jargon.
• Create fuzzy requirements – If you must create a list of the user's requirements, make sure they're as generic as possible. Don't bother detailing what features the finished product will need, because you might want to change it later. Also make sure to include as little detail as possible, and leave the requirements open to speculation. If someone has to ask for clarification on what a feature does more than once, you know you've done your job.
• Don't put effort into design – Design is for hippies, so make sure you only vaguely describe a few bits of the software. Make sure to leave out details on the most important features, and definitely don't describe how people will use the software. Include a few designs scribbled on a beer mat, so you look like you're completely devoted to the project.
• Implement the least important features first – When the client sees you've gone to the effort of implementing some of the least important features, they'll think you've gone the extra mile. Make sure you escape before they realise what you gave them is just a husk of a product. Bonus points for using a smoke bomb in your escape.
• Schedule your time poorly – We all know you're such a cool programmer that you can write a 3D engine in a few days, and that the AI routines are a three hour job for you. Make sure the schedule reflects how awesome you are.
• Swap people around – If you have more than one developer, make sure they all work on something they're least proficient at. After all, this will help them get better, so you're actually doing a good thing!
• Don't specify the level of quality you're aiming for – Your product will totally rock, so don't bother setting any quality goals.

• Don't use source control – There's no point in wasting a few hours setting up a source control system, because nothing bad will ever happen to your code.
• Don't organize yourself – Once work has begun, don't bother interrupting the flow by reviewing your project's progress. Remember – Everything will be all right.
• Ignore ready made components – There's a plethora of well written, fully tested components that can be integrated into your software. Using them will shave precious time off your schedule, and allow you to actually get the damn project out of the door. They're your worst enemy, and you should treat them as such.
• Make everything more complicated – If there's a choice between writing a small module that implements all the functionality you need, and writing a huge set of modules that uses all the latest design patterns you've been reading, you know which one you should choose. Bonus points are awarded for refactoring your code so that each method is only three lines long.
• Don't track bugs - Keeping track of bugs makes it much easier to eliminate them, and that would mean you'd have to waste time fixing things instead of creating cool new code.

Don't panic if your project has actually been completed on time and under budget. There are still plenty of ways you can make sure it never reaches its full potential.

• Don't promote it – Your product is so good, it'll sell itself! Don't ignore the fact that marketing is one of the largest factors in a project's success. Just make sure you do as little as possible. Try including a link in one of your forum signatures, and that should be enough.
• Don't support it – Don't respond to customer emails, and ignore any requests for help. Feel free to add a wiki to your website, and tell people that if they don't know how to do something, they should add it themselves. Remember to be as rude as possible.
• Don't improve it – Once your product is done, it's done. Don't waste time refining it, because we all know that good software is written in one go.
• Ignore feedback – If someone suggests an improvement, no matter how small, you should ignore it.

Remember The real challenge with helping a project to fail is making it look like you tried your best to prevent it. Be as creative as possible when thinking of ways to help your project to its demise, and you'll soon be celebrating a complete disaster.

Check out the developer articles section for more articles on project management, marketing and business improvement.