Seven fundamentals of IT project success

Author: Michael Krigsman

Many folks think large projects usually fail for technical reasons — software that doesn't work as advertised, bugs, and so on. In reality, that's not the case.

In my experience, the most serious project issues come down to misplaced expectations among participants. Fundamentally, problems in human communication lie at the root of most failures.

These expectation and communication mismatches are difficult to detect systematically, because they aren't quantitative or technical in nature. Failures persist despite fancy project management methodologies, precisely because traditional approaches do not isolate and address hidden problems.

These seven points of project success touch on conflicting agendas, multiple perspectives, and a broad range of business-oriented conditions that drive projects to succeed or fail:

1. Business case
2. Stakeholder and user engagement
3. Executive sponsorship
4. Third-party relationships
5. Project management
6. Change management
7. Resource availability

The Project Failures analysis

It's tempting to dismiss these points as obvious or to believe your projects have few problems in these areas. However, successful project managers dig deeper than that. For example, how do you really know that sufficient executive sponsorship is present? If you only asked one or two stakeholders, then your opinion may well be incorrect.

To gauge sponsorship accurately, you must gather perceptions across the project. After all, someone reporting directly to the CIO may have quite a different view than one working 1000 miles away who has never even met the sponsor.

Please do not ignore these seven fundamentals, thinking they are too "simple" or do not apply to your work. They really are that important.

In future blog posts, we'll explore practical steps you can take to uncover the hidden causes of failure that may be present on your projects.

Five job search tips for discouraged job seekers

Author: Toni Bowers


Few things are as discouraging as a long, seemingly futile search for a job. Nothing quite drags the self-esteem down than the long silence after you've sent out a resume.

In their new book, Unlock The Hidden Job Market: 6 Steps to a Successful Job Search When Times are Tough, Duncan Mathison, executive career consultant and former vice president of Drake Beam Morin, and Martha I. Finney, careers expert and employee engagement consultant, encourage job seekers to never give up.

Here they share five tips for job search survival:

1. Prepare for an extended search. When the job market shrinks, it takes longer to land a job. Adjust your finances and your expectations now to extend your staying power. Stopping the search until the economy improves is like the farmer who will go hungry at harvest because they didn't plant seeds in the spring. Do not give up. Keep planting those seeds.

2. Don't waste your time on long-shots. If you are only applying to posted jobs and those seem far and few between, your tendency is to cast a wider net by applying outside your geographic area or outside of your expertise ("I could do that job!"). This is a dead-end strategy and you will only face more painful rejection and depressing stories of 500 applicants to 1 job. When it comes to job postings: focus, focus, focus.

3. The right job for you is out there - it just won't be advertised. Employers cut recruiting budgets when times are tight. Instead hiring managers use less expensive and informal word of mouth strategies. As a result a higher percentage of available positions are in the "hidden job market". Job seekers must significantly expand the quality and quantity of their networking efforts to find unpublished jobs.

4. Leave the resume at home. The secret to good networking is to help your network help you. Instead of a resume, give people in your network (everyone you know) a list of 50-75 employers who you think would hire people with your type of skills. Do not ask if the companies are hiring. Instead ask if anyone knows people who work there - particularly managers who might hire and manage people with your skills.

5. Contact managers directly. Get their name, get an introduction and introduce yourself to them. Your introduction can be a simple, "I understand you have people with my kind of background and skills working for you. I don't assume to know if you have job openings but I would like to meet you and learn more about the type of people you like to have on your team and share with you a bit about my background." They may say "sure", they may say "send a resume" or they may say "no", but now they know about you. Remember the ONLY thing managers can do to assure their success is to meet and hire great people.

Making the case for dynamic languages

Author: Justin James 

Justin James presents reasons why developers should consider using dynamic languages. He also discusses how these languages trip up some developers.
——————————————————————————————————

Dynamic languages, for the most part, are ignored by the typical business developer. Sure, Perl had its flash in the pan moment during the CGI heyday of Web development, but dynamic languages are usually viewed as a niche item.

If you aren't considering using dynamic languages, I think you're leaving a lot of potential utility on the table. Here are three great reasons to take a look at what dynamic languages can do for you.

Metaprogramming is a breeze

Dynamic languages are excellent for metaprogramming. And with that attribute, dynamic languages are a great choice if you're working on a template system,a domain specific language (DSL), a code generator, a parser, or other type of application that can build applications. Can strongly typed, static languages do these things? Sure, but it is typically a lot more work than it is with a dynamic language.

The .NET world contains a number of tools for performing metaprogramming. You can use Reflection.Emit to spit out code; CodeDOM is slightly less painful; and for the current acme of VB.NET or C# metaprogramming, there are T4 templates. Out of those choices, T4 templates are the least effort to use. But by the time you're using T4, you aren't even performing metaprogramming anymore — to begin with, you're programming in a template system. It is my understanding that T4 is essentially just an abstraction layer on top of CodeDOM.

On the other hand, look at what you can do in a language like Ruby, Perl, Python, PHP, or even JavaScript when it comes to metaprogramming. It is a cinch to hash together a templating system. In Perl, for example, the "guts" of one consist of one line of code. Want to make a code generator? That's easy too. And, thanks to eval, you can do some pretty wild stuff in terms of on the fly modifications to business logic, such as allowing per-customer overrides of default functionality while maintaining a single install base in a multi-tenanted application. You can do all of this with very few lines of code and relatively low complexity. The systems practically write themselves.

Cross-platform compatibility

Dynamic languages tend to be much more cross-platform compatible than other languages. The runtime environment takes the guesswork out of the gotchas that you can encounter. There will occasionally be incompatibilities, such as when the language needs to make calls to the underlying operating system. Sometimes the results will not be the same (math functions with large numbers and cryptography are two examples). Even still, you shouldn't need to rewrite or modify the overwhelming majority of applications written in dynamic languages to move from platform to platform.

Code focused rather than structure focused

Dynamic languages often get a bad rap for being too loosey-goosey about architectural principles. Developers who knock dynamic languages on this basis will often call them "scripting languages," with the implication that the languages are really only suitable for gluing together OS functionality or automating an application via an API.

The truth is dynamic languages simply focus on the code. And while dynamic languages can often support the detailed architecture that C++, Java, and C# are capable of, the languages tend to minimize that aspect of programming. This is not always the case. Perl and PHP, for example, have never been truly object oriented at heart, although both are changing in that direction. Languages like Ruby and JavaScript support the kind of enterprise development styles of architecture, but in standard usage, you don't need to deal with it at all.

Possible issues

In my experience, most developers who experiment with dynamic languages find this de-emphasis on structure to be refreshing. Those who do not usually trip up on the following common problems:

Undisciplined programmers writing sloppy code.
In a dynamic language, some of the "safety net" that static, strongly typed languages have is removed. The programmers are trusted to do what the compiler in other languages enforces. While this allows for rapid code writing, it also enables developers who lack discipline to write code that runs but not correctly.

Built-in shortcuts can reduce readability.

Dynamic languages tend to have a lot of built-in shortcuts. Developers who rely on Perl's "implicit variable" usually produce code that is difficult to understand when other developers read it. Ruby has lots of aliases for functionality; this makes the code feel more logical, but it also requires subsequent readers to have an expanded "vocabulary" to know what each of those aliases do.

Flexibility.

Dynamic languages often allow you to override or remove functionality from even the core language. While this can reap huge rewards, it can be confusing. For example, if someone overrides the "print" function (maybe to include application-specific formatting), developers who are not aware of this could end up pretty confused.

Each bullet point shares a common theme: responsibility of the developers (thanks to Chip Camden for pointing me to this post). To put it simply, these languages make the programmer responsible for doing the right thing, instead of enforcing it at the syntax level. Some might compare it to C/C++, but I don't think it's a good comparison. In C/C++, you don't have a choice but to tread on dangerous ground; it's impossible to write anything in C that does actual work without using a pointer. In dynamic languages, all of the potentially problematic features are squarely in the category of features rather than requirements. As a result, you'll find that these languages tend to not expose you to too much danger before you're ready.

Conclusion
Are dynamic languages right for every developer? Of course not. There are some very real problems with dynamic languages, and some of these problems are inherent to their design. Performance will always be a bit slower than other languages (not to say that they are necessarily slow). IDEs will always have a hard time understanding what many areas of code do simply because the code is non-deterministic until runtime. Along the same lines, many pre-runtime tools (such as static analyzers) will not be able to do the same things with dynamic languages that they can do with static languages.

Despite these points, dynamic languages are a potentially useful tool that more developers should consider using in their work.

J.Ja