Showing posts sorted by relevance for query schedule. Sort by date Show all posts
Showing posts sorted by relevance for query schedule. Sort by date Show all posts

Thursday, July 28, 2011

Fitting It Into the Schedule

This title applies to more than one aspect of my Identity Management life these days. I've been very busy which accounts for the lack of blog entries lately.  It's not that I don't have what to write about.  It's more about finding the time to do it.  

I was given an interesting challenge lately.  We have a number of tasks on the current project that only need to run once a month., which is not a frequency that is supported by the IDM scheduler. There's actually a few ways to handle this. Most of which revolve around finding the batch file that is created when job is first run and tying this into the scheduling utility of your choice.

However, I was really interested in finding a way that would work within the IDM framework. So I came up with this little script:

// Main function: scheduler

function scheduler(Par){
//Only run the task on a particular day of the month.
//Should only be called from the Initialization script of a maintenance job.
//Created by: Matt Pollicove 7/7/11
//NW IDM Functions used in this script:
//uStop();
//uGetPassSubject();
//uWarning();
//*****
//NOTE: Requires an external Job Constant called Runday that is set to the
//two digit day of the month that the task should be executed on or this value
//must be hard coded

//Parameters for the task.  Name of the pass/task and what the legal execution day is
var strJobName = uGetPassSubject();
var strRunOnThisDay = '%$runday%';

//What's today's date and what is the actual date.
var strDate = '%$ddm.date%';
var strToday = strDate.substring(3,5);

//Put it all together
if (strToday != strRunOnThisDay){
     uWarning(strJobName + " is not scheduleItd to run on " + strDate);
     uStop();
}         
}

As you can see, it's not terribly complicated, but let's break it down:

The task first grabs the name of the running task for informational purposes.  Then it goes out to find a local constant (feel free to make an adjustment so that it works with a repository or global constant) which holds the day of the month the task should run on.

Once we have this, we do basically the same day with the current date, by getting it from the system parameter %$ddm.date%, and retrieving the date part of the current month.

Then we can compare the two values. If they're equal go ahead, if not, we log a message (another thing that can be taken out if desired) and call uStop().

  1. Now to use this functionality we need to do the following:
  2. Copy/Paste the script listing above into a NW IDM script.
  3. Create the RUNDAY constant.  Remember if you choose to create this as anything other than a job constant, you need to edit the script accordingly.
  4. This script could be used in either a managed task (yellow folder section) or a work flow task (although I'm not sure why). But the script should be placed in the "Initialization script" entry on the source tab of the first pass in the job. When running as a managed task, it should be scheduled to run once every 24 hours.

That's about it.  Hope this works for you.  Please remember to share any edits or improvements.

Monday, February 23, 2009

Managing Project Communication

I've written before on the topic of how to prevent project failures, but very little about what happens as projects are failing. I was recently chatting with some colleagues about what does happen when a project begins to head south.

First of all, there always seems to be a tendency to blame the outsider. Basically this argument looks something like: "You never got the requirements right (from the customer) / you never delivered correct requirements (from the consultant)"

What does this boils down to is a failure in communication. Now the question from a risk management approach is how one keeps this communication in sync. Based on our discussion we came up with the following:

  • Regular status meetings. If your executive sponsor is not at these meetings, schedule regular steering committee updates which should be just the project manager(s), architect(s) and the executive sponsor. They might not need to be weekly, but they must not be optional any of these people. Do not rely on only one side to make these reports.  Everyone must be on the same page. Make sure the sponsor is aware of the key challenges so that there are no surprises.
  • Obtain consensus and settle the issues quickly and decisively. If there are dissenting opinions about major decisions, get the issue settled once. Don't keep circling on the issue. If there's an issue that just won't go away, get the parties in front of the executive sponsor as I've noted above. Get a final ruling and move on.
  • Establish change controls. For some reason, no one likes to use these. There's a feeling that these are things to hide behind, rationalize additional cost or bog down the project in extra paperwork. None of these are true. All that's being done here is making sure that all project principals are aware of the change. This establishes responsibility and sets up controls for making sure that things don't get out of control. And I'd imagine that the amount of paperwork involved in a change control is minor compared to having to write the report of why the project failed. Trust me, this is not fun.
  • Use and establish some sort of project strategy/methodology. I don't care what it is, but make sure a project plan exists and that there is structure in place. There should be a project manager who will make sure that there is a plan to complete the project, but the architect and senior engineers should make sure that there are development standards which must also include documentation!

These points are intended to increase communication and decrease mistrust and politics. If the project team meets regularly, tracks what they are doing and how the project changes and has a structure for managing progress and change there is less of a chance of having a post-mortem and more of a chance of documenting the best practices that were done right!