A Level of Focus

One of the things that I am trying to learn on the job is what level of focus is right for which situation.  When do I need to focus on the details as apposed to taking a step back and looking at the "big" picture.  I was just completing a project that had been left open by the previous manager, and lets just say it went down hill pretty fast.

Looking back, the reason why it went down hill wasnt because of a lack of information, it was all available to me if I wanted it. It wasn't because of a lack of communication, there was regular communication.  It was because my focus was on doing what was always done, without really knowing what it was trying to achieve, or even what was done previously.

Now we were at the "implementation" part of the project, so I was focused on finishing off the "doing" part. What I should have done was taken stock of where things were at, which I did, but then I should have looked and understood the actual requirements.  This step back needed to be the second part of the taking stock that I was doing BEFORE I even started trying to implement the project. I assumed things based on my understanding on of what I thought happened prevoiusly. And therein was my problem.

I was focued on implementing my version of what I was implementing.  And my understanding was wrong.  Not totally, I even understood the overall goal of what the project was trying to achieve.  But the errors in my understanding ment that, at the end of the day, I was doing the wrong thing.  I should have taken a step back and changed my focus to the big picture then as I understood what was going on, then slowly focused more and more on the details as I checked that I understood correctly what was going on.

So, always remember to look at the biggest picture possible first on a project that you are starting to work on.  It dosent matter if you are starting a project from scratch, or picking up a project that is basicly done.  A quick glance at the data flow of the project, reviewing the aims and sitting down with the stakeholders (if you can) to make sure that you understand what you are doing from their point of view. Then refine your focus into the details to complete the project.

Just Keep at It

When projects start to look like they are going to be late, not be delivered or seemingly impossible to complete, there is one phrase that you need to hear.

"Just keep swimming, just keep swimming"

Yes, this may come from a children’s movie, but it doesn’t make it any less important. When all seams lost, don’t jump ship, just keep going. Focus on what you need to do next. Let people know about the issues that are causing the delivery date to slide, or functionality to not be delivered. As the saying goes, the only way to eat an elephant is one bite at a time.

And trust me, things are likely to get worse before they get better. It is the nature of things. Call it Murphy’s Law, it doesn’t matter. The main thing is that you need to keep at it. You can get though; just try your best to stay positive. Get positive people around you who can encourage you to get though.

Anyways, I hope that to those who are in the middle of one of those projects this lifts your spirits and your eyes can see the light (even if it is the size of a pin hole) at the end of the tunnel. And no, it isn’t an oncoming train. :D

It's all in the detail

Have you ever wondered why you complete a project and not gotten the pat on the back for all the hard work? When that happens to me I generally find it is because I have provided the overall concept of what was wanted, but the fine detail was missing.

By detail I mean the simple things like getting the User Experience right. This includes wording and correct spelling (yes, spelling is important); but also the pecieved way that features should work as apposed to the actual way that they work. It might do the same thing, but users generally know what they expect to see, even if they can't communicate that with you.

So, to finish, a word to the wise. While you need to make sure you deliver the project or functionallity, make sure you don't forget the details that will really make the UX just that bit better.

Geneva (and not the place with all the history)

Working on a Geneva prototype has been interesting. The extendability of the framework is awesome, using id management from multiple Security Tokin Services allows for an ease of managing multi-site users with no extra hassle. To understand what I mean, check out the Geneva documentation on the Microsft website, or the MSDN we site.

I would however say that there is somewhere that the framework may be let down. From what I gather, as a basic overview, the STS manages the identity, with the STS of the install, or primary STS, managing all the claims that the Geneva sever passes back to the client. But how does the application update the users details? For an instance using one STS, not a problem, point your appliaction management sections (web-links etc) to management functionallity in the STS. But with more than one STS? How, without making a claim(s) that contains the require data, would the Geneva framework handle that?

From my understanding, there are 2 possible solutions. One is to include the information as part of the claim. This would allow each application to manage the conections between the users and their identity management. The secnd is to use Geneva to send the details to, or show the form of, and have that communicate with the affected STS. How Geneva passed the update through to the STS is up to Geneva, and Geneva could through an exception if it were not possible. Also, the mechanics of the update could be defined at the creation of the trust.

Anyways, I am looking foward to using Geneva. From what I have seen it is a powerful identity platform that will have a great future. Who knows, the theories and practices behind Geneva could become the standard in multi-site identity management.